Can't find field on ROOT_QUERY object error on 3.4.x and up
See original GitHub issueHello,
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'
andnextFetchPolicy: '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 usingrefetch
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.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:9 (6 by maintainers)
Top GitHub Comments
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.
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 alwaysthrow
if theerror
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
tono-cache
fixed the issue. Previously I only tested it withnetwork-only
, but I see now according to the docs thatnetwork-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.