-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Invariant Violation 17 #5291
Comments
What exact versions of the |
This error persists for 2-3 months, so it's there since day 1 we started using Apollo for the piece that causes this Invariant to happen once unmounted while in some unknown state. It's not that straightforward for me to understand what kind of invariant it's (TBH I do not 100% understand the meaning of the term "invariant") I have CRA so adding up some invariant plugin or so is rather hard (possible, but I'm not sure there is Webpack or Babel or whatever version of the Invariant Plugin which, I don't understand what it means and what it does (why not just list of error codes/invariants with explanations?)) Could it be some issue on unmount when there are two records with the same id's but has been fetched using 1 query? So 2 different records of some type, with the same ids in the same response, but slightly different bodies, that drives apollo crazy but only on unmount? |
What version of An |
@benjamn Thanks for the guidance, I'll try to repro on dev env. If I will find and issue I'll let you know and will close the issue (if it's not a bug obviously) Apollo client version:
|
@benjamn we are also getting the same issue on sentry. |
this happened to me today, only in production: |
Yes, I got those error from sentry that those users are using iOS |
Hitting the same issue for our iOS users, error reported in Sentry as |
Same problem on multiple devices. The violation 17 means: "ObservableQuery with this id doesn't exist:" What i found out is that fetchMore queries won't be cancelled and will throw this error. If you are using fetch more you can catch it with try/catch #4114 (comment) |
@MrWook thanks for giving a guess. I think right now I know how it happens and will try to repro and fix this one. It's so annoying it spams a lot of events :( |
When an invariant fails in production, a cryptic numeric error of the form `Invariant Violation: 42` is thrown, with a reference to the error codes section of invariant-packages README.md: https://github.com/apollographql/invariant-packages#error-codes This vague guidance has not proven adequate in many cases, to say the least: see apollographql/invariant-packages#18, apollographql/invariant-packages#19, #6604, However, this vague guidance (which was intended to suggest searching your installed node_modules/@apollo/client package for the error code) has not proven adequate in many cases, to say the least: see apollographql/invariant-packages#18, apollographql/invariant-packages#19, #6604, #5730, #5291, and #5975, to cite just a few of the many issues we've seen since #4521. Using error codes instead of error strings remains important for production bundle sizes, but I think we can make it substantially easier to look up the error string corresponding to each error code, by generating a single file containing all the invariant error codes for each @apollo/client release. Starting with Apollo Client 3.1.0, this manifest file can be found in @apollo/client/invariantErrorCodes.js (using an npm/yarn-installed copy of @apollo/client, since this file is generated in the ./dist directory, not checked into the repository). The file contains an explanatory comment, the @apollo/client version, and a sequential map from error numbers to the { file, node } responsible for the error.
…llographql#6665) When an invariant fails in production, a cryptic numeric error of the form `Invariant Violation: 42` is thrown, with a reference to the error codes section of invariant-packages README.md: https://github.com/apollographql/invariant-packages#error-codes This vague guidance has not proven adequate in many cases, to say the least: see apollographql/invariant-packages#18, apollographql/invariant-packages#19, apollographql#6604, However, this vague guidance (which was intended to suggest searching your installed node_modules/@apollo/client package for the error code) has not proven adequate in many cases, to say the least: see apollographql/invariant-packages#18, apollographql/invariant-packages#19, apollographql#6604, apollographql#5730, apollographql#5291, and apollographql#5975, to cite just a few of the many issues we've seen since apollographql#4521. Using error codes instead of error strings remains important for production bundle sizes, but I think we can make it substantially easier to look up the error string corresponding to each error code, by generating a single file containing all the invariant error codes for each @apollo/client release. Starting with Apollo Client 3.1.0, this manifest file can be found in @apollo/client/invariantErrorCodes.js (using an npm/yarn-installed copy of @apollo/client, since this file is generated in the ./dist directory, not checked into the repository). The file contains an explanatory comment, the @apollo/client version, and a sequential map from error numbers to the { file, node } responsible for the error.
#6665 was merged and released to help make tracing errors like this easier. Please try out a more modern version of |
This is relieving to see other users experiencing the same bug. Can anyone calm my nerves on this by confirming whether it crashes the app/component or is it a silent error that does not affect the user? I have had zero luck replicating the issue but it definitely occurs ~daily (reported by Sentry). |
We have this issue that we detect only on Sentry side. Hence I never encountered it myself during development so I have no idea how to reproduce but here is the error message:
Additional data that sentry provides are:
Any googling around that didn't help me find what can be the cause of that, but I'll be happy if anyone can give me any idea about this one.
The only clue is that it happens when the user leaves the page with one particular Query out to any different route that unmounts component that uses such query. And it always the same one.
The text was updated successfully, but these errors were encountered: