test: add failing test around replaceWith
and refreshModel
#19092
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been trying to see if I can bet to the bottom of what is going on in #18416. I figured I would start with a failing test and work backward from there, but I couldn't get very far before hitting a different failure altogether.
I don't intend to land the test in this partial state, but hope that this can be a starting place for actually fixing this bug.
I want want the test to verify is that, when calling
replaceWith
inafterModel
, the router does not unintentionally push a new state into the history stack, which is what actually happens. However, before I can even get to that kind of assertion in the test, I run into this error:(Screenshot from an ember twiddle I created to make sure that this error was actually happening in a "real" Ember app and not just the test suite. The test suite will fail with the same error.)
What appears to be happening is that the
Transition
object is created without anyrouteInfos
https://github.com/tildeio/router.js/blob/d885da22340da98dcadb45427766efade54ce832/lib/router/router.ts#L123-L130
but then those
routeInfos
are passed around to a number of functions that expect them to exist as a side-effect of callingfinalizeQueryParamChange
.I am going to assume that this is a fix that will need to at least start in
router.js
and then continue through to here, but figured I would at least post this PR as some small step toward getting to an actual fix.