-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Failing test case for lazily loaded engines with loading states #19266
base: main
Are you sure you want to change the base?
Conversation
163d69e
to
022375c
Compare
@rwjblue any idea why that job is failing? I tried to parse the logs but they're making my eyes bleed... |
@rwjblue I've forked this branch and rebase against master. https://github.com/sly7-7/ember.js/tree/failing-test-case-for-engines I turns out there are 2 failing tests. The first one is resolved by adding an undefined check in the router microlib I think it's legit, because after reading a bit the router code, I find out that when route are lazily loaded, they can be Concerning the second failing test, I have doubt, if either it's a brittle test, or if the bug is in the router. If I understand correctly your goal when adding those tests, you would simulate routes lazy loading. In this case, I guess this involves some kind of asynchronous behavior. But seeing those three lines: I think we should be waiting for the async process to finish before sending the second and third actions. As you can see, the first call to editPost triggers the lazy load of the edit route, but there is a missing 'waiter' somewhere, so I think the transition is aborted by the 'showPost' action. After that, the second call to edit post works, because this time, the route has been loaded. So at this point, I'm just confused, because I don't know if it's a bug, or if the test should be adapted to take the async behavior in account. |
Ok, so there is definitely some kind of mess with asynchrony. The test now "passes", but probably for wrong reason, because I must call |
@rwjblue Unless I'm missing something, this is the thing landed in 3.25.3 right ? |
I think we still need to add the guard in router_js |
Creates a separate set of tests that leverage async loaded routes (roughly akin to what ember-engines does) to ensure model loading and loading states work correctly in that scenario. Currently, this emits the following error: ``` TypeError: Cannot read property '_stashNames' of undefined at stashParamNames (http://localhost:7021/tests/ember.js:23926:13) at Class.setup (http://localhost:7021/tests/ember.js:20365:37) at _routeEnteredOrUpdated (http://localhost:7021/tests/ember.js:62215:17) at PrivateRouter.routeEnteredOrUpdated (http://localhost:7021/tests/ember.js:62230:9) at PrivateRouter.setupContexts (http://localhost:7021/tests/ember.js:62159:16) at PrivateRouter.getTransitionByIntent (http://localhost:7021/tests/ember.js:61969:14) at PrivateRouter.transitionByIntent (http://localhost:7021/tests/ember.js:61905:21) at PrivateRouter.doTransition (http://localhost:7021/tests/ember.js:62040:19) at PrivateRouter.intermediateTransitionTo (http://localhost:7021/tests/ember.js:62522:19) at Class.intermediateTransitionTo (http://localhost:7021/tests/ember.js:22389:28) ```
022375c
to
695b2bf
Compare
I've rebased against master (fixing up some merge conflict issues). |
Also, FWIW, it is easiest to review without whitespace (https://github.com/emberjs/ember.js/pull/19266/files?diff=split&w=1) because I re-indented a bunch of the tests... |
I think that will fix this test:
|
@rwjblue Yeah, I'm into that right now, and sorry, I thought I had pushed a PR in the router.js. |
Is this still relevant? It is a draft and seems to have a successor PR |
Creates a separate set of tests that leverage async loaded routes (roughly akin to what ember-engines does) to ensure model loading and loading states work correctly in that scenario.
Currently, this emits the following error:
This was introduced by fixing another issue (that the original state was not preserved when doing intermediated transitions) over in:
Those changes don't directly cause the issue, but the issue was masked due to the bug that they fixed.
This affects Ember 3.22.1 (and current 3.23 betas).