Clarification requested for use of GraphQLQueryWatcher

[damian0815]

Question

I've setup a watch on a fairly complex "overview" graphql query which includes many nested fragments. I'm running a mutation that touches one of these fragments. I'm expecting that the watcher will call my callback with an updated version of the "overview" query result reflecting the mutation, but this is not happening.

When I put a breakpoint in Apollo's GraphQLQueryWatcher public func store(_ store: ApolloStore, didChangeKeys changedKeys: Set<CacheKey>, contextIdentifier: UUID?) it's fairly obvious why. All of the changedKeys begin with MUTATION_ROOT:

whereas the dependantKeys begin with QUERY_ROOT:

and so naturally dependentKeys.isDisjoint(with: changedKeys) returns true and the query callback does not run.

It's unclear to me how this is supposed to work. Do the key prefix mismatches suggest a misconfiguration on my part? I am using the default store and I have not touched cache settings. Is there an example I'm missing in the documentation of a non-trivial watched query with a mutation that successfully triggers the watch callback?

[calvincestari]

Hi @damian0815 - it seems like you're missing the configuration to normalize the response objects with Custom Cache Keys. Without custom cache keys the cache reference is resolved back to the operation root which as you're seeing can be a query or a mutation.

Take a read through that documentation and let us know if you have any issues getting it to work.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.

[damian0815]

@calvincestari The watcher is now reliably responding to mutations - thanks for the pointer. I have two problems now:

1. How can I get the watcher to fire again if a deletion mutation deletes one of the objects that my "overview" graphql query references? I have tried manually removing the objects from the cache but as I understand from the documentation on removeObject this doesn't have any flow-on effects.
2. Crash in GraphQLQueryWatcher.cancel() and GraphQLQueryWatcher.refetch() #3476 - my attempt to brute-force an update by manually calling refetch() after deleting an object results in a crash. Current workaround is to .cancel() the GraphQLQueryWatcher and build a new one, but I would like to understand why refetch() is crashing.

[calvincestari]

How can I get the watcher to fire again if a deletion mutation deletes one of the objects that my "overview" graphql query references? I have tried manually removing the objects from the cache but as I understand from the documentation on removeObject this doesn't have any flow-on effects.

This is because even though the object itself has been removed from the cache, the lists that reference that object have not been updated; this is the flow-on effect you're looking for. To get that list updated you need to do a local cache mutation for the query that contains the list and remove the item you deleted. Does that make sense?

my attempt to brute-force an update by manually calling refetch() after deleting an object results in a crash. Current workaround is to .cancel() the GraphQLQueryWatcher and build a new one, but I would like to understand why refetch() is crashing.

I'll reply to this in #3476.

[damian0815]

To get that list updated you need to do a local cache mutation for the query that contains the list and remove the item you deleted. Does that make sense?

yes it does, although I'm not sure of the details - thanks