Condition-rejected duplicate queries prematurely flush delayed invalidations

Author: OskarEichlerCreated Aug 30, 2026Updated Aug 30, 2026

Problem

The delayed-invalidation handler increments its pending counter for query/mutation pending actions, but decrements it for every fulfilled/rejected thunk. A duplicate query rejected by createAsyncThunk’s condition emitted no corresponding pending action, so it still decrements the counter for the original in-flight query.

Observable race

  1. Cache a tag-providing query.
  2. Force-refetch it and keep that request pending.
  3. Dispatch a duplicate initiation, which is condition-rejected.
  4. Complete a tag-invalidating mutation.
  5. Complete the original refetch.

On current master (74200d87), the invalidation flushes at step 4 while the query is still pending. Its attempted refetch is condition-rejected and the queued invalidation is lost, leaving the stale step-2 response cached.

Expected

Only terminal actions that correspond to a previously counted pending request should decrement the counter. Query condition rejections should not release delayed invalidations.

I have an integration regression using a controlled request queue and a one-condition guard in the invalidation handler.