Watching separate instances of ApolloQueryCall pointing to the same data (Android)

Help
, ,
1

This is a question for the Apollo-Android library

I have a scenario where I am trying to create a watcher on a query which is defined like this:

val query = apolloClient.query(MyQuery()).toBuilder().responseFetcher(ApolloResponseFetchers.CACHE_ONLY).build()

And then watching this query like this:

query.watcher().toFlow().collect(){}

I have another query similar to the one above, but its response fetcher is set to NETWORK_ONLY

val remoteFetchQuery = apolloClient.query(MyQuery()).toBuilder().responseFetcher(ApolloResponseFetchers.NETWORK_ONLY).build()

When the remoteFetchQuery query runs, and updates the cache, it seems that the watcher that I defined earlier does not trigger. Is this a usecase that is supposed to the supported in Android?
From my testing and code inspection it appears that watchers are associated to a query and only respond to the changes made to cache by the query, and not a separate query, even though the database rows affected are the same.

Thanks!

2

I would expect this to work, especially if it’s the same query in both cases.

The normalized cache is a bit different from a regular database in that it stores “records” instead of rows. You can read more about it there: Demystifying Cache Normalization - Apollo GraphQL Blog

If this is still not working, I would recommend dumping the cache after the NETWORK_ONLY query to double check that data has been written correctly. Instructions how to do this can be found there: https://www.apollographql.com/docs/android/essentials/normalized-cache/#troubleshooting

3

Thanks @mbonnin for the quick response.

The data appears to be written correctly with the keys resolved to be unique. The watcher still does not trigger. Is there any debug information that I can provide that might help with this issue?

Thanks again!

4

Can you provide a reproducer? If not, can you share your GraphQL query as well as the cache dump? I can try to see if there’s anything obvious.

5

Thanks @mbonnin I think I might have found the issue. I had a bug in the CacheKeyResolver which was not returning stable IDs. When I started doing that, the watchers started firing as expected.

Thanks for the help!

6

Thanks for the update! Glad you found a solution :+1: