Can't find field on ROOT_QUERY object error on 3.4.x and up

[hueter]

Hello,

After upgrading to 3.4.x, I have had problems with certain queries being reissued with different variables resulting in an Apollo error that crashes my app.

Intended outcome:

useQuery can be re-executed multiple times with different variables and not crash.

Actual outcome:

This crash happens:

Following the traceback, I placed a debugger in ObservableQuery at getCurrentResult:

Note that the network request worked and the backend resolved the query successfully:

How to reproduce the issue:

I am having a lot of difficulty reproducing the error in the sandbox, but here's a bunch of things that I tried / additional information:

• The affected queries have deeply-nested arguments, where subsequent queries change things that are deeply nested, e.g.

{
 "limit": 25,
 "offset": 0,
 "filters": [ /* deeply nested objects w/arrays. This is what changes between queries */ ]
}

• This error still happens when I do fetchPolicy: 'network-only' and nextFetchPolicy: 'network-only'
• Still happens when I call refetch with new variables or the same query with new variables
• I also tried doing skip: true and only using refetch and it still happened
• Also tried this setting on the apollo client instance after reading the CHANGELOG and it did not resolve the issue:

new ApolloClient({
  defaultOptions: {
    watchQuery: {
      refetchWritePolicy: "merge",
    },
  },
})

Versions

I reproduced this error on the following:

• 3.4.0
• 3.4.1
• 3.4.5
• 3.5.0-beta.4

However downgrading to 3.3.21 fixed the issues.

Additional Notes

I'm wondering if this could possibly be related to #8422 because it touched the file where I'm getting the error.

Please let me know if there's anything to try or if any additional info would be helpful.

[benjamn]

@hueter I believe this may be a consequence of #8262, which came before #8422 (though that's a reasonable suspect too). The motivation for #8262 was to avoid situations where both result.data and result.error are undefined, by providing a result.error with information about missing cache fields. That behavior is new in v3.4, so we're definitely still open to feedback on how it works in practice.

Can you tell where the error is actually logged/thrown? The stack trace attached to the error shows where the ApolloError object was created, but it would also be useful to know where/why result.error got logged/thrown (and whether it happened in application/component code or inside @apollo/client).

[hueter]

hi @benjamn thanks for the reply and context. For context, yes we usually throw errors that come from apollo queries and catch them with parent error boundary components like so:

[benjamn]

On a different note, I'm also curious to figure out why the field was missing in the first place. Do you see any keys starting with contactsCollection in the __APOLLO_CLIENT__.cache.data.data.ROOT_QUERY object, around the time the error is logged?

[hueter]

Yep, before the error, during the debugger statement (while the error is being initialized), and after the error is thrown, I had two keys:

[benjamn]

In case this is useful, you can control the serialization of the contactsCollection field arguments using a keyArgs field policy:

new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        contactsCollection: {
          // Use keyArgs to configure args serialization:
          keyArgs: ["params", ["order"]], // Serialize only args.params.order, not limit or offset
          keyArgs: false, // Disables the serialization, so the key is just contactsCollection
        },
      },
    },
  },
})

However, I should also mention these MissingFieldErrors are meant to be information and not fatal. If we're causing more problems than we're solving by providing result.error when a cache read is incomplete, that's an argument for not reporting result.error for these errors.

[hueter]

Ah interesting, thank you for the insight! I guess it's a tough call from the API design perspective, but as an end user I was expecting result.error to be present only if it were fatal -- although I know some folks might expect partial failures with GraphQL, so I'm not sure if I should change my assumption to always throw if the error is present. Would this be related to the error policy settings, i.e. is there an error policy that lets me ignore non-backend / network errors?

I also just tested the code and setting the query's fetchPolicy to no-cache fixed the issue. Previously I only tested it with network-only, but I see now according to the docs that network-only still writes to the cache after the network request is complete.

I'll have to read up on the caching serialization to see if that could provide an alternative as well.

Thanks for the follow-up! This has been helpful.

[brainkim]

Related: #8442

I’m also seeing transitory Missing Cache Field errors on the error property in unit tests while refactoring code. A potential option might be to make these console warnings only.

[benjamn]

@brainkim I've got an idea for a PR to handle this, coming shortly!

[benjamn]

@hueter @brainkim Please take a look at #8604 when you have a chance!