Generic errors with no message on production builds

[GreenGremlin]

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]

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]

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

[GreenGremlin]

@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]

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.

[nathantqn]

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]

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

[michaelknoch]

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

[jasonalmaturner]

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]

EDIT: Thanks @benjamn - All good here!

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