websocket-invalidate ({refetchType: 'none', cancelRefetch: false}) + refetchInterval => sometimes staleData

[cproinger]

We are using websocket-messages to invalidate specific keys as described here https://tkdodo.eu/blog/using-web-sockets-with-react-query (using react-query 4 at the moment)

because a lot of these invalidation-websocket-messages are pushed by the server we do not want to do an API-Call for every single one of them. instead we just invalidate like this:
queryClient.invalidateQueries({ queryKey: qk, refetchType: 'none' }, { cancelRefetch: false });
this in combination with a specific refetchInterval-function does achieve our goal in most cases

const q= useQuery({
      queryKey, queryFn
      keepPreviousData: false,
      cacheTime: 300 * 1000,
      staleTime: Infinity,
      refetchInterval: (_, query) => {
        if (query.state.fetchStatus === 'idle' && query.state.isInvalidated) {
          return 5000;
        }
        return false;
      },
    },
  );

however, since https://github.com/TanStack/query/blob/v5.28.8/packages/query-core/src/query.ts#L562 sets the isInvalidated state to false whenever an API-Call returns successfully. invalidations happening between the start of the API-Call and its return are ignored (~lost-update). so it may be that the server manages to create a result that is at that point already stale. the client continously gets invalidation-messages until a batch of work is finished. when the API-Call returns with stale data, the invalidation-messages it gets during the API-Call are not considered.

In my opinion: Instead of only keeping a boolean flag as state-information about the fact that a queryKey was invalidated, react-query should store an invalidation-timestamp that is used in some meta-data when calling the queryFn so it can decide, when the API-Call returns, if the invalidation-timestamp it has is still unchanged or if a new invalidation was made in between.

if you at least could store the invalidation-timestamp besides the isInvalidation flag and make it accessible the same way, i could implement the rest on top of it for myself, but i think that this will be a very common use-case

alternatively/additionally: some options for refetch-delaying on invalidation instead of refetchType=none + refetchInterval would be nice

[TkDodo]

1. setting cancelRefetch: false does nothing if you combine it with refetchType: 'none'. If you are not refetching, there is nothing to cancel.

2. your refetchInterval function will stop doing anything when it gets called once where data is fresh. You'll never get another interval then, unless your component re-renders for some other reason. Imo, you should return a longer interval time here (the maximum time where you'd want to see at least one fetch).

invalidations happening between the start of the API-Call and its return are ignored

yes, that's why we default invalidation to cancelRefetch: true, so that a call to invalidateQueries will always be made. But you're actively opting out of that with your settings.

alternatively/additionally: some options for refetch-delaying on invalidation instead of refetchType=none + refetchInterval would be nice

you should be able to build that in user-land with something like p-throttle to make sure that invalidateQueries isn't called too often. I would probably just do that in the socket callback over the interval (that will also likely miss cases as shown above).

[cproinger]

thanks for the suggestion. p-throttle seems to do every call, just delayed. looking at https://github.com/sindresorhus/promise-fun p-debounce seems more suited. so p-thottle + cancelRefetch=false seems to do the trick for me.

sidenote: the behavioural difference between the fetchInterval- and the debounce-solution is that while with the refetchInterval solution the queries have the state "stale" and not immediatly "fetching", the debounce-solution does