SSR crashes with "invariant violation" when InMemoryCache uses "possibleTypes" and "error-policy" is set to "all"

[ZauberNerd]

Intended outcome:

When a GraphQL resolver fails to resolve a field, @apollo/client should render as much data as possible (with errorPolicy: all) and should populate the error field of useQuery.

Actual outcome:

The server process crashes with an "Invariant violation" error:

Invariant Violation: Missing field 'bar' in {
  "foo": "bar"
}
    at new InvariantError (~/workspace/tmp/apollo-client-ssr/node_modules/ts-invariant/lib/invariant.js:16:28)
    at ~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/cache/cache.cjs.js:791:103
    at Set.forEach (<anonymous>)
    at StoreWriter.processSelectionSet (~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/cache/cache.cjs.js:762:17)
    at StoreWriter.writeToStore (~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/cache/cache.cjs.js:711:29)
    at InMemoryCache.write (~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/cache/cache.cjs.js:1390:37)
    at InMemoryCache.ApolloCache.writeQuery (~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/cache/cache.cjs.js:53:21)
    at ~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/core/core.cjs.js:890:31
    at perform (~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/cache/cache.cjs.js:1493:17)
    at InMemoryCache.performTransaction (~/workspace/tmp/apollo-client-ssr/node_modules/@apollo/client/cache/cache.cjs.js:1508:13) {
  framesToPop: 1,
  name: 'Invariant Violation'
}

How to reproduce the issue:

1. find / mock a response with a broken resolver
2. set errorPolicy to all on your query
3. define possibleTypes for the InMemoryCache
4. wittness the crash

Here is a reproduction: https://github.com/ZauberNerd/apollo-client-ssr-reproducer

Versions

  System:
    OS: Linux 5.8 Arch Linux
  Binaries:
    Node: 12.16.0 - ~/.nvm/versions/node/v12.16.0/bin/node
    Yarn: 1.22.4 - ~/.nvm/versions/node/v12.16.0/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v12.16.0/bin/npm
  Browsers:
    Chrome: 84.0.4147.135
    Firefox: 79.0
  npmPackages:
    @apollo/client: ^3.1.3 => 3.1.3

[ZauberNerd]

Hi @benjamn @hwillson have you had some time to look into this?
Or could you give me some pointers on where to start, so that I could prepare a PR myself?

[benjamn]

@ZauberNerd Since the bar field has an error, I believe it needs to be null rather than missing from the result object.

See the Errors section of the GraphQL spec, or this explanation of null in GraphQL responses from Hasura.

In other words, the following change seems to be the "right" way to fix the problem:

diff --git a/src/server.ts b/src/server.ts
index f2f67d2..54379ae 100644
--- a/src/server.ts
+++ b/src/server.ts
@@ -14,7 +14,7 @@ app.get('/', async (_, res) => {
 
 app.post('/graphql', (_, res) => {
   res.json({
-    data: { foo: 'bar' },
+    data: { foo: 'bar', bar: null },
     errors: [
       {
         message: 'Could not resolve fields',

As it happens, this particular exception used to be a warning (in AC2, before #6055). I might be open to switching back to a warning, but I think the content of the warning indicates something useful even in this case (an invalid GraphQL response).

[RadoslavGenov]

@ZauberNerd Have you found a way to mitigate this error? Did you refactor all of your resolvers? Or have you decided to not migrate yet?

[ZauberNerd]

Hi @RadoslavGenov @benjamn yes, thank you for the great explanation. I have followed it and updated my GraphQL mock server, so this ticket can be closed.