Asynchronous caching and subsequent reads

[rohandhruva]

Question

We use asynchronous caching for almost all our operations. Are the cache writes vs subsequent reads guaranteed to be consistent or locked when using asynchronous caching?

So for example:

• client.query(foo), we got the response, but it's still writing to cache
• immediately follow it up with, say, client.watch(foo)

Is this second operation guaranteed to hit the cache (assuming it's the exact same operation)? Or can it miss the cache if the previous operation is not done writing to it? Or in other words, are cache reads locked against any ongoing writes?

And along similar lines, when using asynchronous caching, is there any way to get a signal that write to cache has completed? For example, if we use .toFlow(), we can get one ApolloResponse<D> followed by a completion event when it's done writing -- does that seem like something that can be done?

Thank you!

[martinbonnin]

Is this second operation guaranteed to hit the cache (assuming it's the exact same operation)? Or can it miss the cache if the previous operation is not done writing to it? Or in other words, are cache reads locked against any ongoing writes?

There is nothing like this. writeToCacheAsynchronously uses a separate coroutine in a separate scope so it's "fire & forget". It can take 1ms or 20s and subsequent reads happen concurrently.

And along similar lines, when using asynchronous caching, is there any way to get a signal that write to cache has completed?

Nothing like this at the moment.

does that seem like something that can be done?

We could swap the order of the two lines here. Meaning you could rely on the Flow terminating to know that the cache went through but that would remove the guarantee that "cache is written by the time you receive the event".

[rohandhruva]

We could swap the order of the two lines here. Meaning you could rely on the Flow terminating to know that the cache went through but that would remove the guarantee that "cache is written by the time you receive the event".

Removing that guarantee is definitely not ideal, and I imagine it will break a lot of current code that's working under this guarantee.

I am also not sure if swapping the order of the lines will actually work: when asynchronous caching is enabled, I see that we are using launch { }. Maybe it is enough to just wait on that job to complete before finishing the flow?

[rohandhruva]

Maybe it is enough to just wait on that job to complete before finishing the flow?

I have submitted a proposal for this in PR #5877, but there is a caveat when you use .execute() or executeV3: let me know what you think, and maybe we can close this out in favor of that PR?

[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 Kotlin usage and allow us to serve you better.