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

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 https://github.com/apollographql/apollo-client/pull/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.

[brainkim]

Related: https://github.com/apollographql/apollo-client/issues/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.

[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.