Hi We re observing some strange behaviour when using `cache

Question

Hi We re observing some strange behaviour when using `cache only` fetch strategy namely our Flow with that strategy fails with a network exception Is it possible that a query with cache only fetch strategy makes or triggers by refetching some previous query a network call

mbonnin · Answer

Since it s a Flow I m assuming a `watcher` is involved somewhere

mbonnin · Answer

not that it should really matter it feels like `cache only` should never reach the network but trying to understand

wasyl · Answer

Yep it s `watcher toFlow ` somewhere deeper

wasyl · Answer

Basically we re making the same query twice first with `Cache Only` strategy and then with `Network Only` We expect the first one to just wait until the second one fetches data and emit the same thing However we re observing two network requests being made

mbonnin · Answer

I remember some cases where the `fetchStrategy` was ignored because the return value was ignored the API is a bit weird

mbonnin · Answer

let me check if I can find the issue

mbonnin · Answer

Could it be related to <https github com apollographql apollo android issues 2430>

mbonnin · Answer

Calling `ApolloQueryCall responseFetcher ` returns a new `ApolloQueryCall` and if the return value isn t used it s lost forever

wasyl · Answer

I m pretty sure we properly chain the calls always ~but you did point me to one piece of our code which might be messing with things let me check that~

wasyl · Answer

It s most certainly not that confused And I just verified that we watch the query with network only strategy exactly once and it still makes two network calls thinking face

mbonnin · Answer

confused

mbonnin · Answer

Any chance you can share some code or pseudo code

wasyl · Answer

We re working on some repro but without luck confused

mbonnin · Answer

Mmmm could it be another watcher that trigger the network call

mbonnin · Answer

When data is normalized it s hard to keep track of who s listening to what key

wasyl · Answer

gt could it be another watcher that trigger the network call But then should the network call be returned from the Flow started with cache only fetch strategy gt it s hard to keep track of who s listening to what key Definitely we already fixed a bunch of places where we didn t request normalized cache `id` for a given type but only in some queries This resolved some issues and now we re pretty sure we re requesting all `id`s There is another query which fetches part of the same data that the one that s failing though

mbonnin · Answer

gt But then should the network call be returned from the Flow started with cache only fetch strategy It shouldn t How do you know the data came from the network `isFromCache == false`

wasyl · Answer

I m sorry I meant `network error`

mbonnin · Answer

Ah right

mbonnin · Answer

What is the exception you re getting

mbonnin · Answer

Maybe we re mapping to a network error for something else that wouldn t be great but you never know

wasyl · Answer

Basically we have ```query Foo foo fooData bar barData query Bar bar barData ``` Foo is started twice with `cache only` and with `network only` strategy Bar is started once with `cache and network` We observe the Foo network only query returning successfully with data Foo cache only fails with network error We re investigating which `Bar` might be an issue now because we do have something like 5 6 queries being made it seems confused

wasyl · Answer

gt Maybe we re mapping to a network error for something else Unlikely the exception is clearly a network error it has cause with some OkHttp type with timeout specified etc

mbonnin · Answer

Is `Foo network only` a watcher as well or is it one shot

mbonnin · Answer

There s this issue about multiple watchers calling each other <https github com apollographql apollo android issues 2226> But I have never been able to reproduce

wasyl · Answer

gt Is `Foo network only` a watcher as well or is it one shot It s a watcher but we terminate it immediately with `first `

mbonnin · Answer

So you re basically doing this ```apolloClient query FooQuery responseFetcher ApolloResponseFetchers CACHE ONLY watcher toFlow collect println it data ``` And this throws a ApolloNetworkException

mbonnin · Answer

That s weird the `CACHE ONLY` stuff is pretty explicit about bypassing the network

wasyl · Answer

Yep exactly The flows are pretty much straightforward we do have some mappers and stuff along the way but there s no real chance we d do something weird

mbonnin · Answer

It would still be interesting to see that exception stacktrace

mbonnin · Answer

If everything goes well there shouldn t be any sign of `ApolloServerInterceptor` there

wasyl · Answer

We just isolated the change that triggers this issue and it s fetching a completely unrelated query with `CACHE FIRST` strategy And it s a query for extremely simple object no ids no nothing

wasyl · Answer

Just an update this is part of the stack trace that s particularly suspicious ```at com apollographql apollo internal RealApolloQueryWatcher refetch RealApolloQueryWatcher java 115 at com apollographql apollo internal RealApolloQueryWatcher$1 onCacheRecordsChanged RealApolloQueryWatcher java 40 at com apollographql apollo internal RealApolloStore publish RealApolloStore java 117 at com apollographql apollo internal interceptor ApolloCacheInterceptor$7 run ApolloCacheInterceptor java 218 at com apollographql apollo internal interceptor ApolloCacheInterceptor publishCacheKeys ApolloCacheInterceptor java 215 at com apollographql apollo internal interceptor ApolloCacheInterceptor cacheResponseAndPublishSynchronously ApolloCacheInterceptor java 170 at com apollographql apollo internal interceptor ApolloCacheInterceptor cacheResponseAndPublish ApolloCacheInterceptor java 159 ``` specifically the chain `cacheResponseAndPublishSynchronously` gt `onCacheRecordsChanged` gt `refetch`

mbonnin · Answer

Sorry for the late response Good catch looks like the default reftechResponseFetcher is `CACHE FIRST` <https github com apollographql apollo android blob 3e122b4ff44fff3109911dd24177aeddce5d3426 apollo runtime src main java com apollographql apollo internal RealApolloQueryWatcher java L32|https github com apollographql apollo android blob 3e122b4ff44fff3109911dd24177a a com apollographql apollo internal RealApolloQueryWatcher java>

mbonnin · Answer

So maybe something like below would do ```apolloClient query FooQuery responseFetcher ApolloResponseFetchers CACHE ONLY watcher refetchResponseFetcher ApolloResponseFetchers CACHE ONLY toFlow collect ```

mbonnin · Answer

I would have expected the default `refetchResponseFetcher` to be the same as `responseFetcher` but maybe there s a reason why it s not the case

wasyl · Answer

Will check it out

wasyl · Answer

If anyone stumbles on this thread in the future it turned out that we were observing two separate issues query watchers would always use `CACHE FIRST` refetch strategy even if the query was specified as `CACHE ONLY` so a cache only queries would still make a network call on a cache miss where queries that didn t yet receive any response `CACHE ONLY` are the easiest ones would trigger a refetch even when a completely unrelated query populated the normalized cache Many thanks to Martin for taking the time to figure this out slightly smiling face