Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache write on watcher dependent key can cancel server fetch #1155

Closed
flobories opened this issue Apr 14, 2020 · 3 comments
Closed

Cache write on watcher dependent key can cancel server fetch #1155

flobories opened this issue Apr 14, 2020 · 3 comments
Labels
Milestone

Comments

@flobories
Copy link
Contributor

I recently updated my project to 0.25 from 0.20 and observed some unexpected behavior in request cancelations.

Intended outcome
Network requests on watched queries are not interrupted by cache updates.

Actual outcome
If a cache update comes in while a server fetch is in flight, the server fetch is canceled, and a .failure is sent to the completion handler.

How to reproduce the issue

  • Watch a query with a cache policy that includes a server fetch
  • While the server fetch is in flight, modify a dependent key in the cache in a read/write transaction
  • The fetch is canceled

I believe this behavior was introduced by #1012 in 0.22
It appears that if a dependent key of the watcher is written to, a cache fetch is triggered, effectively canceling the in-flight server fetch, and issuing a .failure to the completion handler.

Here is a concrete example of how this is playing out in my project, which features a list of chat conversations:

  • If some conversations are unread, the user can navigate to a carousel of unread conversations. This list of conversation was previously fetched and is available in the cache.
  • When the users navigates to the carousel of unread conversations:
    • UnreadConversationQuery is watched with .returnCacheDataAndFetch
    • The cached list is returned and the first conversation displayed. The server fetch is issued.
    • The first conversation marks itself as read
      • isRead is set to true optimistically in the cache for this conversation
    • Since UnreadConversationQuery depends on this same isRead key, the server fetch is canceled and replaced by a cache fetch.
    • The watch result handler is called with a .failure
@RolandasRazma
Copy link
Contributor

considering #1156 was merged is this still open issue?

@designatednerd
Copy link
Contributor

@RolandasRazma I leave these open until the version ships, but thanks for asking!

@designatednerd
Copy link
Contributor

This has been released with 0.28.0!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants