I wrote about this early this week in Guide: When and how to handle asynchronous side-effects in testing?
My understanding of Ember.run is that it immediately runs the callback supplied to it, and then runs the RunLoop algorithm of flushing all the queues
The point of calling Ember.run is to allow the RunLoop to track all of the async calls and make sure that they’re executed completely. One caveat is that its possible to create a scenario where a function executed by Ember.run triggers a callback that runs after the RunLoop stops running.
In my scenario, the 3rd party library called setTimeout, which caused the original function to finish executing and triggered the start and finish of RunLoop before the setTimeout expired. As a result, the callback of the setTimeout executed outside of the RunLoop.
you expect things to happen immediately that would otherwise be deferred, such as appending a view to the DOM.
Its not being called immediately, it’s just handling the deferred side effect within the RunLoop.