Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Invariant violations are not searchable using previous methods. #5975

Closed
toddtarsi opened this issue Feb 21, 2020 · 1 comment
Closed

Invariant violations are not searchable using previous methods. #5975

toddtarsi opened this issue Feb 21, 2020 · 1 comment

Comments

@toddtarsi
Copy link

toddtarsi commented Feb 21, 2020 •
edited
Loading

Intended outcome:
Invariant violations need to be consistent and be able to be looked up by the same code in development or staging or production or wherever.

Actual outcome:
Invariant violations don't match across environments. Invariant violations aren't able to be looked up using previously described techniques.

Error code from staging:

Screen Shot 2020-02-20 at 6 16 32 PM

After reproduction in development environment:

Screen Shot 2020-02-20 at 11 34 49 PM

Searching this error code in my development environment:

Screen Shot 2020-02-20 at 11 39 50 PM

Sorry about how small these images are, but basically one environment gives me an invariant violation error code of 53, and the other environment gives me an invariant violation error code of 8 for the same error. That's not good, and everything about how to decode these errors kinda falls apart when this occurs! 😱

How to reproduce the issue:

Perhaps this is something about how I'm building. I'm using Webpack + React-Loadables and perhaps something in the tree-shaking / chunking logic is throwing everything off. If that is the case, I'm not sure how to put together a minimum reproduction.

Versions

Screen Shot 2020-02-20 at 6 56 31 PM
@benjamn benjamn mentioned this issue Jul 21, 2020
Merged
benjamn added a commit that referenced this issue Jul 21, 2020
@benjamn
Generate @apollo/client/invariantErrorCodes.js for each release. (#6665)
877885c 
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.
jimrandomh pushed a commit to jimrandomh/apollo-client that referenced this issue Jul 22, 2020
@benjamn @jimrandomh
Generate @apollo/client/invariantErrorCodes.js for each release. (apo…
e80835f 
…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.
@hwillson
Copy link
Member

#6665 was merged to help with this. Thanks!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hwillson @toddtarsi