Async/await in model hooks fail in tests

[simonihmig]

Given a model hook that uses async/await and calls Ember.set after an await statement, this will fail in an acceptance test visiting that route, with an You have turned on testing mode, which disabled the run-loop's autorun. You will need to wrap any code with asynchronous side-effects in a run error. This does not happen when rewriting this using Promises.

If I understand this correctly, the root issue seems to be that native Promises do not integrate into the Ember run loop, while RSVP.Promise do, and is the same as reported in #15240 and emberjs/rfcs#175. But I thought creating this issue here would help others getting bitten by this to find this.

As reported elsewhere, a workaround is possible by

• replacing the native Promise in tests with the RSVP one: window.Promise = Ember.RSVP.Promise;. (you can add that e.g. to tests/index.html)
• making sure your targets.js is configured to make Babel transpile async/await. Using native async/await in e.g. Chrome does always lead to those failing tests.

[offirgolan]

Here is a working twiddle to demonstrate this issue in a component.

Ember Twiddle

[pixelhandler]

The work around for window.Promise as RSVP.Promise seems to be the only way. Since async/await is only supported via babel / regenerator, we are betting on the future.

Seems legit to hedge that bet with an initializer like the example in the RFC, emberjs/rfcs#175 (comment)

[alvincrespo]

@pixelhandler Thanks for providing background on this - totally just helped me.

[offirgolan]

@pixelhandler regenerator isn't available if your only targets are the latest browsers which means that overwriting the global promise class wont work 😢.

Is there a workaround for that?

One way that I can think of is to force add regenerator by dynamically adding an older browser to the targets if the env is test. The only issue with that is now your test env wont be the same as your prod env.

[caseywatts]

I believe RSVP.Promise (but not the global Promise) knows to notify the Ember run loop after each promise resolution (although I can't find where in the code I think that happens...)

Eventually (hopefully) none of us will have to use the regenerator any more. It seems that in the long-term, we may need the global Promise to have a hooks thing like RSVP.Promise does. I'm not sure the state of that right now, or how to find out.

[jrjohnson]

@offirgolan this issue is actually keeping us from targeting only modern browsers. I'm hoping the new testing setup in RFC #232 will surface this with more apps and maybe a better solution will show up.

[pixelhandler]

@simonihmig @jrjohnson @caseywatts @offirgolan @alvincrespo Perhaps this post sheds some light on the considerations for running with async/await ...

http://rwjblue.com/2017/10/30/async-await-configuration-adventure/

[offirgolan]

@pixelhandler no, not really. @rwjblue is writing about setting up your app and test suite to support async / await. This issue is about async / await promises not being fulfilled in tests since Ember has no knowledge of them. As stated before, this happens when you target only the latest browsers which have no need for regenerator.

[caseywatts]

Thanks for sharing @pixelhandler !

Related to rwjblue's blog post - I've found that async/await already totally helps with tests!
Some ways: https://gist.github.com/caseywatts/7c01654f74fbe402dfaadfa144965adb

But it's not ready to be used inside our Ember app code yet:
emberjs/rfcs#175 (comment)

[rwjblue]

Hoping to kickstart more efforts to enable this, but we should probably track the actual issue over on emberjs/rfcs#175 (which I think predates this issue a bit). I'll try to chime in over there with a quick status update and lay out the game plan that @krisselden is coaching me on...