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

Generic errors with no message on production builds #4519

Closed
GreenGremlin opened this issue Mar 1, 2019 · 9 comments
Closed

Generic errors with no message on production builds #4519

GreenGremlin opened this issue Mar 1, 2019 · 9 comments
Assignees
@benjamn
Labels
📦 bundle size 🧞‍♂️ enhancement 🚀 shipped 🛠 tooling
Milestone
Release 2.6

Comments

@GreenGremlin
Copy link

Version 4.2 graphql-anywhere included a change that stripped messages from some errors (invariant violations) in production builds. This change resulted in very generic errors that are very difficult to track down. I'm curious why the decision was made to strip messages from errors that ARE still thrown. I can understand preventing warnings in production builds, but stripping messages from errors that ARE still thrown does not make sense to me. Furthermore, there was no mention of this change in the changelog, and it was released as a minor version bump!

For us this was an even bigger issue, because we were relying on the error message to handle the errors caused by #4372. The undocumented removal of invariant error messages resulted in generic errors in our production builds that could not be reproduced in our development builds.

Please at least document these types of changes, in the future! And consider adding back invariant violation error messages.
@benjamn
Copy link
Member

benjamn commented Mar 2, 2019 •
edited
Loading

Sorry for the surprising change. I agree this should have been better documented.

Stripping error strings from the production bundle cuts 10-20% from bundle sizes (depending on how many error strings are used). Very few build-time optimizations have that much impact on bundle sizes (besides minification and gzip, of course). I'm open to refining how this system works, but it's very unlikely that we will ever go back to embedding the full strings in the bundle. The pressure from developers who want smaller bundle sizes is not something we can ignore (see #4324).

Throwing an exception changes control flow, so it's important to continue throwing even if the error message has been sanitized. For cases where throwing in production is not desirable, we have invariant.error and invariant.warn (see source here). If you believe certain invariants should become non-fatal in production, please let us know so we can use the weaker versions in those cases.

The stripping of error strings happens only when process.env.NODE_ENV === 'production', so you may be able to adjust your build settings to use a different NODE_ENV value, perhaps on a per-package basis? We chose this approach because it's the same approach React uses, but perhaps we should have made our version more opt-in, so that fewer people would be surprised by it, though far fewer people would automatically benefit from it.

I realize this isn't trivial because of security considerations, but if you have the ability to enable source maps in production, it might be easier to figure out where the exceptions are being thrown.

@benjamn benjamn self-assigned this Mar 2, 2019
benjamn added a commit to apollographql/invariant-packages that referenced this issue Mar 2, 2019
@benjamn
Annotate sanitized InvariantErrors with numeric error codes.
19008e6 
Inspired by apollographql/apollo-client#4519.

Given the { errorCodes: true } option, rollup-plugin-invariant will now
transform

  invariant(condition, message)

into

  process.env.NODE_ENV === 'production'
    ? invariant(condition, <number>)
    : invariant(condition, message)

and

  new InvariantError(message)

into

  process.env.NODE_ENV === 'production'
    ? new InvariantError(<number>)
    : new InvariantError(message)

so that production errors can be traced back to the place in the
unminified source code where they were thrown. Since the full development
version of the error is always colocated with the production one, it
should be relatively easy to determine the nature of the error.

The message for these sanitized errors will look like this:

  Invariant Violation: <number> (see https://github.com/apollographql/invariant-packages)

The provided URL is appended by the InvariantError constructor within the
ts-invariant package, so it will not be repeated at every call site.
@benjamn benjamn mentioned this issue Mar 2, 2019
Merged
benjamn added a commit that referenced this issue Mar 2, 2019
@benjamn
Assign unique error codes to production invariant errors.
3081ba2 
Inspired by #4519.

Implemented and explained by apollographql/invariant-packages#1.
@benjamn benjamn mentioned this issue Mar 2, 2019
Merged
@benjamn
Copy link
Member

benjamn commented Mar 2, 2019

@GreenGremlin Please have a look at #4521 when you get a chance!

@GreenGremlin
Copy link
Author

@GreenGremlin Please have a look at #4521 when you get a chance!

That's great! Any chance you could take a look at #4373, which fixes the original issue that led to my fix that relied on the error messages?

benjamn added a commit that referenced this issue Mar 4, 2019
@benjamn
Assign unique error codes to production invariant errors.
d668ca4 
Inspired by #4519.

Implemented and explained by apollographql/invariant-packages#1.
benjamn added a commit that referenced this issue Mar 4, 2019
@benjamn
Assign unique error codes to production invariant errors. (#4521)
251b14e 
Inspired by #4519.

Implemented and explained by apollographql/invariant-packages#1.
@benjamn benjamn added this to the Release 2.6.0 milestone May 6, 2019
@benjamn
Copy link
Member

benjamn commented May 21, 2019

Closing since we just published the final version of [email protected] to npm, including the fix for this issue! See CHANGELOG.md if you're curious about the other changes in this release.

@benjamn benjamn closed this as completed May 21, 2019
@nathantqn
Copy link

nathantqn commented Jul 18, 2019 •
edited
Loading

Hi @benjamn, thanks for the PR, but may I ask is there any way for me to track the error based on the errorCode. I'm not sure where to start. E.g I got the error
Invariant Violation: Invariant Violation: 2 (see https://github.com/apollographql/invariant-packages)

Then what next, where should I use the number 2 to see what is the exact error?. Thank you

@valerybugakov
Copy link

valerybugakov commented Jul 19, 2019 •
edited
Loading

@GreenGremlin @benjamn same question here. Got Invariant Violation: 15, what's the way to find the message behind error number?

@michaelknoch
Copy link
Contributor

same for me, Invariant Violation: 14 in our react native app with. Do you have any ideas by now ? @valerybugakov @nenjamin2405 @benjamn

@jasonalmaturner
Copy link

jasonalmaturner commented Jul 31, 2019 •
edited
Loading

This is an option for finding the message associated with the error number: #4521 (comment)

It's pretty tough to determine production errors, since the numbers might not always be the same for each error. #4521 (comment)

The most helpful way I've found for deobfuscating the production errors is using source maps and go up the stack trace to find usable error messages.

@toddtarsi
Copy link

toddtarsi commented Aug 1, 2019 •
edited
Loading

EDIT: Thanks @benjamn - All good here!

If anyone is still having issues, this may help: #4521 (comment)

@TheoMer TheoMer mentioned this issue Aug 25, 2019
Closed
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@benjamn benjamn

Labels
📦 bundle size 🧞‍♂️ enhancement 🚀 shipped 🛠 tooling
Projects
None yet
Milestone
Release 2.6
Development

No branches or pull requests
7 participants
@benjamn @GreenGremlin @valerybugakov @toddtarsi @michaelknoch @jasonalmaturner @nathantqn