FYI I opened https://github.com/apollographql/apollo-android/issues/2899 which is super weird, and we spent better part of recent days chasing it down. I’m available for clarification if needed, esp. if it’s non-reproducible for Apollo folks

Thanks for the awesome reproducer, I can reproduce as well

Is it published somewhere?

Is it published somewhere?

Not yet, there will be snapshots once it is merged. If you have the repo checked out locally, you can do

./gradlew publishToMavenLocal

and add

mavenLocal

to your repositories to try it out.

Thanks a lot 🙂 We can’t apply

.toFlow() -> .await()

fix in our codebase because abstractions, also we create watcher quite early and there’s no

.await()

on that. And testing on CI would be slightly too complicated if we had to build the library locally, so we’ll have to wait for a snapshot. I could only confirm I don’t observe the issue on my repro project anymore with the snapshot

👍👍I just merged the pr. Snapshots should start to appear in ~30min

🙏 we’ll test it first thing tomorrow 🙂

The store has 2 listeners. The first one throws so the second one doesn't get the update

So the

ApooloStore#publish

is just posted on some executor, this call is not interrupted by anything? And the race condition is that with working case, we’d have: • network call completes, posts runnable to publish cache changes • watcher is canceled, unsubscribes

recordChangeSubscriber

• store publishes the changes And the not working case would be that • network call completes, posts runnable to publish cache • store starts publishing the changes, gets the first subscriber •

first()

cancels the flow, so the watcher is cancelled • store calls the first subscriber’s callback but it’s already canceled and throws exception ?

Seems the most recent snapshot fixes the issue for us

Nice glad to hear that! 🎉

Is there any release planned soon or not yet?

There's not much activity in the main branch these days so releases tend to stretch a little bit. Ok if I do one on monday? I like Monday releases

Sure, no worries 🙂

I just want to understand better how Apollo works internally, as it’s quite helpful sometimes

Sorry I missed the question above. No problem at all, brainstorming is good and we can have more people know about the internals 👍

If the watcher is cancelled, it unregisters the listener though, right? So the cancelling would’ve had to happen already after dispatching the runnable and acquiring reference to still-not-unregistered listener?

Mmm good call

I think that’s why it’s happening so rarely. So my last question: if the

publish

call is just a runnable on a dispatcher, what happens with the exception? Is it thrown just to stop some potential further processing? Is it logged? Because as I understand it shouldn’t be propagated anywhere to the app code

So the cancelling would’ve had to happen already after dispatching the runnable and acquiring reference to still-not-unregistered listener

Right, would need to happen somewhere here:

val recordChangeSubscriber: RecordChangeSubscriber = object : RecordChangeSubscriber {
    override fun onCacheRecordsChanged(changedRecordKeys: Set<String>) {
      if (dependentKeys.isEmpty() || !areDisjoint(dependentKeys, changedRecordKeys)) {
        // scheduling would need to happen somewhere here 
        refetch()

I think I got it 🙂 I think the missing piece for me was that publishing cache updates was a posted runnable, and not part of making an actual call. That is, I though

writeToCacheAsynchronously=false

would mean that publishing is also synchronous. But it’s not, just saving to cache is synchronous, publishing the changes is not

The fix is released: https://github.com/apollographql/apollo-android/releases/tag/v2.5.3