Ember.run.later sometimes does not execute callback on time

[dschmidt]

Hi,

I'm seeing something that looks like a race condition to me that sometimes stops run.later from working.
More concretely:
It looks like runs get stuck in the runloop, they aren't executed after the specified time but only when something else starts a new runloop, for example if I click on something and the DOM changes or even more interesting, it's even enough to put another Ember.run.later into the JS console: then it looks like a runloop is started again and the scheduled runs are processed.

This is the minimal example I could reproduce this with:
http://emberjs.jsbin.com/siboromaho/1/edit
I need to run it up to 80 times to trigger the behaviour ... :-
When you see that some foo isn't printed to the console you can press the "start runloop" button and it will get printed to the console immediately.

The next example is closer to what I'm doing in my app but it is also slightly more complicated, you don't need to include the SomeView but if you do, it's triggered way more often.
http://emberjs.jsbin.com/xulibakupe/1/edit

The examples look a bit artificial but it's what happens in my app through setting properties and observers. AFAICT I need the Promise in there and also the new Èmber.run.later in the then function, without it I can't reproduce in my app even - or it just reduces the probability so far that if you remove it you hardly ever trigger it.
FWIW I'm on Chromium 39

Best regards,
Domme

[stefanpenner]

ouch, something seems funky. I suspect this may be an issue with https://github.com/ebryn/backburner.js

[ppcano]

I confirm this issue, we use multiple Pollers which makes use of run.later to execute a function periodically. Then, a run.later callback randomly stops all other run.later callbacks of being executed and they will only be restarted when the stopper Poller is executed again.

Changing run.later for setTimeout has solved the problem at the moment.

[chesterlaw]

Can confirm as well. We use run.laters to poll an API, as well as do animations in components, and all of them stop at the same time. Visiting the ember inspector will also start the run.laters to start again.

[stefanpenner]

Is this cross platform or just a specific browser? If there is a repro it'll be easier to debug. Otherwise someone needs to audit back burners timers

[dschmidt]

@stefanpenner well, I provided those jsbins?
I saw it in Chromium on Linux and @oxidus reported to me several times that he had issues with Ember.run.later not firing and he is on OSX.
He usually is on Chrome, not sure if he tested exactly that with e.g. Safari. Anyway replacing it with setTimeout always circumvented the issue for us

[stefanpenner]

@stefanpenner well, I provided those jsbins?

oops didn't notice, added to my queue for later this week.

[raytiley]

Just ran into this too.

[igorT]

I can consistently reproduce it in a friend's app, will have a chance to take a look wednesday

[igorT]

Here is a JSBin that can consistently reproduce the issue:
http://emberjs.jsbin.com/zelapesiro/1/edit
Note that console.log('a') doesn't fire when it should

[rwjblue]

Looks like there is an issue open upstream for this now. I'm not sure anyone has time to dig in though...

[sushanthkamath]

with Ember.run.next(this,functionName) callbacks are inconsistent

[rwjblue]

@reemasaluja - Not sure that is related to this issue.

[workmanw]

@reemasaluja @rwjblue FWIW I think Ember.run.next is related in this case. We experienced this issue too with Ember.run.next and updating backburner.js seem to resolve the issue (See: #12193).

[sushanthkamath]

Thanks

[rwjblue]

This was fixed in BackburnerJS/backburner.js#151.