Errors returning partial data lead to caching broken data

[Urik]

Version run: 3.12.4

I've run into what (I think) is undocumented behavior in the Apollo Client cache.
The issue is that when a field is returned as null due to an error in the resolvers chain and the errors policy is set to all, that field will end up cached as null and break other parts of the application that rely on the cache.

On my end I'd have believed that any response containing errors would avoid caching its responses to avoid caching potentially broken data or that we'd have an option to achieve said behavior but haven't been able to find it.

The issue is as follows when running 3 queries with errorPolicy: "all":
We ask for the following data: { me: { organization: { name, threads } } }

1. The first query brings back correct data.
2. The same query is then run but the resolver for threads fails, the error bubbles up all the way to organization, organization is returned as null and is cached.
3. Another query asks for { me: { organization: { name } } } running fetchPolicy: cache-first . Nothing should fail here, but because the user corresponding to me is found in the cache, the api is not hit and organization comes back as null.

You can see a working example of this in here (open file App.tsx the preview running in port 5173): https://codesandbox.io/p/devbox/6w5n83

Is there something that I'm missing, or how would you recommend handling this issue?
Thanks.

[phryneas]

-- this was an accidental response to another issue --

[phryneas]

This is the intended behaviour—by setting all, you indicate that you want to use the returned data regardless of whether an error is present.

If the server returns null, the client can't just assume that the currently cached value is in any way correct - it might be heavily outdated/wrong at this point, so the only correct course of action is writing the null to the cache, removing the potentially very outdated value that would result in a teared interface.

If that's not the behaviour you want to use for your application, none is probably the correct error policy in your case.