useSuspenseQuery does not respond to cache updates when the component unmounts, then remounts

[jerelmiller]

Issue Description

While working within the Spotify demo, I noticed that useSuspenseQuery is not responding to cache updates after the component unmounts. At least this is my suspicion. If I load some data on a page, leave the page, then navigate back to it, I am no longer able to get cache updates. See the reproduction steps for an example of this happening.

I was able to confirm that useQuery does not have this issue. If I follow the same reproduction steps with useQuery, I get cache updates as expected.

This appears to only be an issue with the cache-first fetch policy. cache-and-network and network-only fetch policies receive cache updates as expected.

Link to Reproduction

Spotify demo

Reproduction Steps

While using the Spotify demo:

1. Navigate to the Settings page in the user menu.
2. Add a couple field configs.
3. Leave the page and visit another one
4. Navigate back to settings
5. Try and remove one of the field configs

You'll notice that nothing happens. If you inspect the cache with Apollo Dev Tools, the cache is properly updated, however useSuspenseQuery is not properly updated with the updated cache data.

[johnknoop]

@jerelmiller were you able to find out the cause of this?

[jerelmiller]

@johnknoop unfortunately not quite yet. I've been digging pretty deep on this one, but I still haven't quite figured out the root cause. I was hoping #10601 would have fixed this one as well, but alas, no such luck. I'm hoping I can figure it out soon!

[jerelmiller]

Writing my findings down as I've discovered a reason the cache isn't properly updated. I still have a bit to figure out why it gets in this state, but this should help in the discovery process.

After a mutation is run, we run queryManager.broadcastQueries() to notify all observables that new data has been written to the cache. This in turn calls queryInfo.notify(), which then determines if it should actually notify listeners by calling its shouldNotify function. One of the checks in shouldNotify is checking whether the networkStatus is still in-flight. I noticed this bug occurs when networkStatus is set to 1 (loading), but when its working, the networkStatus is set to 7 (ready). It makes sense why the the broadcast fails to notify anything in this case.

The question is why networkStatus is set to 1 in these cases and why it never seems to get back to a ready state. Even weirder is the fact that result in useSuspenseQuery is set to the correct value, a clear mismatch between it and the queryInfo that is meant to represent that value.

Still a bit more digging to determine why its kept in this state. If I were to guess at this point, I'd suspect that when we are able to read from the cache, observableQuery.getCurrentResult() returns a networkStatus of 7 (since the data is all there), which means we avoid calling observableQuery.reobserve(), which is necessary for everything to get to the point where it can call queryInfo.markReady(). Assuming this is the case, useSuspenseQuery will need to account for this and ensure queryInfo.markReady() can be called in some way.

[jerelmiller]

Finished with #10651

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.