-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Microtask update introduced event dropping #332
Comments
Closed by #335 |
I'm seeing a small amount of test failures in the Ember 3.1 betas where async test helpers are not resolving in the proper order, would this issue be related? |
The BB update to use microtasks was only included in 3.1.0-beta.1 through beta.3, it is not included in beta.4 or higher (and will not be included in 3.1.0 final). The update was specifically reverted due to this bug report (which we think we have fixed btw). |
@rwjblue excellent, thanks for confirming. I'll open an issue against Ember then, although I'm at a bit of a loss as to how best to get a useful reproduction other than the tests used to work and now they don't 🌵 |
This was fixed by #336, and the version of backburner using microtasks is included by Ember since 3.2.0-beta.1. |
Copied from the excellent writeup @ef4 did in emberjs/ember.js#16296:
Hello fans of timing bugs, today I have a fun one for you.
The new microtask-based autorun architecture can drop scheduled events. To see it in action, you can run the following against 3.1 beta:
If you fire the
testIt
event, the console logsThe number of layers of promises required to experience the bug depends on which queue you're trying to schedule. The runloop spends one microtask per queue, so our stack of promise resolutions is interleaved with each queue's flush. In the above example, we schedule on the
actions
queue immediately after that queue has just flushed, and the runloop never notices.You can make it drop events on any other queue just by varying the number of promises you resolve in between the time you first trigger an autorun and the time you schedule your doomed event.
I published a working example of the bug here: https://github.com/ef4/bug-repro/tree/bad-timing
The text was updated successfully, but these errors were encountered: