Assign unique error codes to production invariant errors.

[benjamn]

Should help address #4519.

Implemented and explained by apollographql/invariant-packages#1.

[hwillson]

Great stuff - thanks @benjamn!

[GreenGremlin]

This is great! Would it be possible for the error codes to be there in both the production and development versions?

[benjamn]

The error codes will be present in Apollo Client library code in development, since the unminified code looks like this:

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

The codes won't be automatically included in the error messages in development, though. I think this is a reasonable balance, since these error codes are subject to change, so we don't want to commit to specific numbers for specific errors. The goal of this PR is just to make sure it's possible to make sense of production errors.

[skuridin]

@benjamn is there a way to decode these numbers without knowing the apollo-client codebase?

Invariant Violation: 10

I don't even know where to start.

[rshk]

@skuridin best way I found so far is running:

grep -r invariant node_modules/**/bundle.cjs.js

Then try and guess which package actually raised the invariant error (error codes are unique per package, not globally).

---

May I ask what's the rationale behind this btw? (hiding error messages in production). Doesn't seem like something that actually needs to be kept secret from the client? And doesn't seem to be improving performance either.

[toddtarsi]

@rshk - This doesn't work all of the time. I recently tried with a development build, looking for a code 14. Nothing. Skipped right over 14. There was a 13 and 15, but no 14 like we're seeing in production. 😦

[benjamn]

Did you try searching for both invariant and InvariantError?

@rshk This has been one of the more effective ways of reducing bundle sizes, since those error strings can be long and they do not minify.

[toddtarsi]

@benjamn - THERE IT IS! 🤦‍♂ You are right. Thank you sir. I'll delete my comment on the other thread.

To note everyone, I was missing my error, but this resolved that:

grep -r InvariantError node_modules/**/bundle.cjs.js

[nosovsh]

Any possibility to determine the error type dynamically?
e.g. fetchMore doesn't have the possibility to cancel request, so if your component gets unmounted while request is still executing you will get "Invariant Violation: ObservableQuery with this id doesn't exist: XX" in development mode or "Invariant Violation: 17" in production.

Since this error is not really a "error" I don't want it to appear in logs so I want to put fetchMore in "try...catch" and suppress there, but I don't want to accidentally suppress some other error. I can not do e.message === "Invariant Violation: 17" since 17 can change with the next build.

So my question whether it is possible to know that code "17" corresponds to "ObservableQuery with this id doesn't exist" in code and not with grep

[Grohden]

It's really frustrating. Invariant error codes can be repeated in packages, so without sourcemaps we can't tell which error is actually happening.

➜  keepfy-app git:(testing/codepush) ✗ grep -r "InvariantError(8)" node_modules/**/bundle.cjs.js
node_modules/apollo-cache-inmemory/lib/bundle.cjs.js:        throw process.env.NODE_ENV === "production" ? new _tsInvariant.InvariantError(8) : new _tsInvariant.InvariantError("Can't find field " + info.fieldName + " on object " + JSON.stringify(info.object, null, 2) + ".");
node_modules/apollo-client/bundle.cjs.js:      reject(process.env.NODE_ENV === "production" ? new _tsInvariant.InvariantError(8) : new _tsInvariant.InvariantError('QueryManager stopped while query was in flight'));

And why the URL doesn't point to some place useful like a doc or something?
Network error: Invariant Violation: 8 (see https://github.com/apollographql/invariant-packages)

It's not helpful at all to point to invariant-packages repo.

[benjamn]

@Grohden There's an explanation of error codes in the README.md of that repository.

[Grohden]

@benjamn I mean 'doc or something' like a place where the codes are documented (well, technically, they're documented on the code, but multiple packages with same code makes this unhelpful)... anyway, invariant could point which package is triggering this (force some the package to inform it maybe?), then the grep multiple return wouldn't be a problem.

Maybe add an anchor (https://github.com/apollographql/invariant-packages#error-codes) and document a way about how to find the error codes (eg: grep) could make things better...

[toddtarsi]

@benjamn - This is definitely falling apart as a method. Deliberate codes are needed here. Invariant codes are no longer matching up, even when using the same method. If your error codes only work with source maps live, you have a problem.

To provide a little more context, I have a fixed version of Apollo Client, but when I build locally vs when I build in an environment like AWS Codebuild, things stop matching. One environment matches the error up with code 19, and one environment may match the error up with code 10.

As a result, the only way I can truly match up an error in ApolloClient is to reproduce the error in dev. It's very disappointing.

[toddtarsi]

@benjamn - Nevermind, I'm an idiot. I'm looking at your invariant stuff, and it seems pretty much 1:1 with how react does stuff. I'm just flustered and confused. Somehow I was getting an error code that matched up with 19 in my staging environment, something about an invalid string or something having to do with SSR. I built locally, assuming everything was going to be the same since they're on the same version. However, when I ran it locally in dev, the error was about using an invalid fetchPolicy for mutations, and I checked where this was in the codebase, and it matched up with error code 10. I don't know why something like that would occur, and it frankly scares the willies out of me. I need to get my source maps working again >_<