Option to not cache query response using `@defer` when there are errors present

[quinndev4]

I am using Apollo client v4.0.6 with node 20.15.1

The problem I am facing is that when executing a deferred query, the query will stop if there are any GraphQL errors on any field. So if one field errors, the entire query is stopped and not cached. This is fixed by using errorPolicy: 'all' or errorPolicy: 'ignore' in the useQuery() options; however, now when there are errors, the result of the query will still be cached.

I'm looking for some kind of feature so that I can continue streaming the query until completed upon encountering a GraphQL error but have the final result NOT be cached. I only want my query to be cached when it has completed without any errors. I could not find any docs thats could help when calling InMemoryCache(), ApolloClient(), or useQuery()

My initial thought is an additional error policy similar to all that does not cache on errors
https://www.apollographql.com/docs/react/data/error-handling#graphql-error-policies

[jerelmiller]

Hey @quinndev4 👋

So if one field errors, the entire query is stopped and not cached.

This is partially true. Incremental chunks that have successfully streamed until the error are cached, so you still might have some data written to the cache, just not any data from the chunk that contains the error (to avoid writing nulls to the cache for those fields). So its still possible you're writing some data to the cache if errors occur in later chunks.

---

That said, this is certainly an interesting idea. There are a lot of complexities here though that I'd love to noodle on that you perhaps might have ideas on. If we wait to write to the cache, you introduce these problems:

First, you might introduce UI tearing if data in the incremental chunk overlaps with other query data already on screen. The component requesting the deferred query would see the incremental chunks, but because the cache write is avoided, overlapping data on other parts of the screen become stale and out-of-sync until the final chunk arrives.

Second, its much more difficult to deal with other cache writes that occur in the middle of streaming. Imagine a defer chunk that streams in, gets displayed on screen, then another part of the app performs a cache update that affects data in that deferred chunk before streaming is complete. Because the other cache update is newer, we'd want to persist that change to the final result. If the cache write happens when streaming is complete, there is risk the outdated value from the defer chunk is written to the cache.

I think we'd need to solve for the second issue for something like this to be viable. If we can solve for the first, that would be awesome, but that one might be a more acceptable trade-off.