Forced refetchQueries isn't updating cache when key is changed during fetch

[krashdifferent]

I'm seeing an issue with force refetching queries when the query key changes during the refetch

Workflow:

• A mutation is performed on a object in cache with a significant stale time
• refetchQueries is used on the relevant query key with the force option
• Before the fetch can return, the query key given to useQuery is set to undefined
• Some time after the refetch has returned but before the data is "stale" the original query key is used again
• Instead of getting the updated values, useQuery returns the original cache before the refetch was requested

codesandbox used to replicate the issue: https://codesandbox.io/s/black-dream-l20v5?file=/src/App.js

A bit of an edge case but one users quickly found. Current workaround involves using the refechQueries promise to lock out the UI in ways that prevent the query key from changing until the refecth completes. This creates a less responsive UI for the 90% use case. Is there another way to mark the cache as stale before staleTime is reached?

[tannerlinsley]

Just so we're on the same page. This is what's happening:

• Query instances are based on query keys and their usages
• When a query key has no more active instances, any in-flight promises to their fetchers are also marked as cancelled
• Cancelled, but successful fetch responses (if they are not aborted) are ignored and their results are not persisted to the cache

In your case, when the key toggles to undefined and there is no longer an active instance to the original query key, the promise is cancelled and the result is never persisted to the cache. Then, when you bring back the new key, since the staleTime is cranked up, it thinks that the data is up to date (when it was in fact, cancelled and not persisted) and doesn't trigger a refetch.

Sound right?

[tannerlinsley]

Version 1.2.3 should fix your edge case by ensuring that cancelled query requests always result in a query being marked as stale. This way, when the key is restored and the previously cached data is immediately rendered, the query's stale state will result in an immediate refetch.

In simpler terms, an aborted or cancelled query due to a query key change will take precedent over a previous staleTime to ensure it will be refetched next time it is mounted, if ever.