-
-
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
Exception thrown from _fullyScopeQueryParams #14010
Comments
Having the same. But from what I can see it's a timing issue because of the inconsistent reproduction case. |
Also having this issue since upgrading to 2.7 |
Having the same issue after upgrading to 2.7.0 |
Still experiencing this bug in Ember 3.1.2 and not able to come up with a consistent reproduction strategy. As I've had this happen when transitioning between routes that don't have query parameters. (we have a global qp on the application controller, but has never been used when I experience this error
which points to this line in
|
Thought of a possible easy fix change this ember.js/packages/ember-routing/lib/system/router.js Lines 937 to 939 in 169ad48
to check for
|
Since upgrading to 2.7, our app has been throwing errors in production on some transitions. We have around 600 errors recorded in the past week.
I haven't been able to reproduce these in a development environment, so all I have to go on is a stack trace. But it looks to me like there's something going askew on the path from
transitionTo
to the new_fullyScopeQueryParams
introduced in #13273 by @raytiley.The error we're seeing is:
(The exact query param searched for varies.)
Looking at the definition of this method, the only use of the
in
operator is against itsqueryParams
argument, which therefore must somehow beundefined
.Backing up the stack trace, this parameter is set in
transitionTo
, and the only path I can see where it could possibly be undefined is this code:I can't find anything in our app or dependencies that is doing strange things with queryParams in links or transitions, but my knowledge of the router guts ends here.
So while I'm stuck about the root cause, all I can suggest is that we could add a fallback. If the queryParams property of the popped arg isn't an object, default to
{}
, as in the other branch of the if statement.Would that approach be acceptable? Or can anyone suggest further steps I could take to track down the root cause of the bug?
The text was updated successfully, but these errors were encountered: