Skip to content

fix: resetQueries predicate filter no longer matches after reset#11012

Open
highoncomputers wants to merge 1 commit into
TanStack:mainfrom
highoncomputers:fix/resetQueries-predicate-refetch
Open

fix: resetQueries predicate filter no longer matches after reset#11012
highoncomputers wants to merge 1 commit into
TanStack:mainfrom
highoncomputers:fix/resetQueries-predicate-refetch

Conversation

@highoncomputers

@highoncomputers highoncomputers commented Jul 1, 2026

Copy link
Copy Markdown

When resetQueries is called with a predicate filter (e.g. predicate: (query) => query.state.status === 'error'), calling query.reset() changes the query state before the refetch step. The predicate would then no longer match the reset queries, causing them to never be refetched and remain stuck in pending.

Fix: Capture matching query hashes before resetting the queries, then refetch those exact queries using the captured hashes rather than re-applying the original predicate.

Closes #10705

Summary by CodeRabbit

  • Bug Fixes
    • Improved query reset behavior so only the matching queries are refetched after a reset.
    • If no queries match the reset criteria, the operation now completes immediately without extra work.
    • This helps make query refreshes more consistent and avoids unintended refetches.

When resetQueries is called with a predicate filter (e.g. filtering by
query state status), calling query.reset() changes the query state before
the refetch step. The predicate would then no longer match the reset
queries, causing them to never be refetched.

Fix by capturing the matching query hashes before resetting, then
refetching those exact queries.

Closes TanStack#10705

Co-authored-by: TkDodo <TkDodo@users.noreply.github.com>
@coderabbitai

coderabbitai Bot commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

QueryClient.resetQueries now captures matched queries and their queryHash values prior to calling reset(), then refetches using a predicate that matches those captured hashes instead of reapplying the original filters to refetchQueries, ensuring queries whose state changed during reset are still refetched.

Changes

resetQueries refetch fix

Layer / File(s) Summary
Capture query hashes before reset and refetch by hash predicate
packages/query-core/src/queryClient.ts
resetQueries collects matching queries, resets each one, builds a Set of their queryHash values, early-resolves if empty, and calls refetchQueries with a predicate matching those hashes rather than reapplying the original filters.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Caller
  participant QueryClient
  participant QueryCache
  participant Query

  Caller->>QueryClient: resetQueries(filters, options)
  QueryClient->>QueryCache: findAll(filters)
  QueryCache-->>QueryClient: matching queries
  QueryClient->>Query: reset() for each query
  QueryClient->>QueryClient: build Set of queryHash values
  QueryClient->>QueryClient: refetchQueries({type: 'active', predicate: hash in Set})
  QueryClient-->>Caller: Promise resolved
Loading

Related issues: #10705 (resetQueries does not trigger refetch on errored queries)

Suggested labels: bug, query-core

Suggested reviewers: TkDodo

🐰

A query reset, then off it goes,
refetching by hash, not by the filter it chose,
errored ones pending no more in the dark,
a rabbit's small hop, but a meaningful mark.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly describes the main fix to resetQueries refetch behavior after reset.
Description check ✅ Passed The description explains the bug, root cause, and fix, but omits the template's checklist and release impact sections.
Linked Issues check ✅ Passed The code captures matching queries before reset and refetches those exact hashes, matching issue #10705.
Out of Scope Changes check ✅ Passed The change is narrowly scoped to resetQueries refetch logic and adds no unrelated behavior.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
packages/query-core/src/queryClient.ts (1)

256-283: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Hardcoded type: 'active' drops caller's type filter override.

The previous implementation refetched via { type: 'active', ...filters }, so a caller-supplied filters.type (e.g. 'inactive' or 'all') would override the default. The new implementation always passes type: 'active' with no way to override it, so queries reset via resetQueries({ ..., type: 'all' }) or type: 'inactive' will no longer be refetched even though they match the hash set built from the original filters.

🔧 Proposed fix to preserve the caller's `type` override
       return this.refetchQueries(
         {
-          type: 'active',
+          type: filters?.type ?? 'active',
           predicate: (query) => queryHashes.has(query.queryHash),
         },
         options,
       )
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/query-core/src/queryClient.ts` around lines 256 - 283, The
resetQueries implementation is hardcoding refetches to active queries and
ignoring any caller-provided type override in QueryFilters. Update the
resetQueries method in QueryClient so the refetch criteria preserve the original
filters’ type behavior instead of always forcing type: 'active'; use the
existing filters/queryHashes flow to keep the caller’s requested type (such as
all or inactive) when calling refetchQueries.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@packages/query-core/src/queryClient.ts`:
- Around line 256-283: The resetQueries implementation is hardcoding refetches
to active queries and ignoring any caller-provided type override in
QueryFilters. Update the resetQueries method in QueryClient so the refetch
criteria preserve the original filters’ type behavior instead of always forcing
type: 'active'; use the existing filters/queryHashes flow to keep the caller’s
requested type (such as all or inactive) when calling refetchQueries.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 891e5bfb-6291-4350-9885-84a0842e1c3f

📥 Commits

Reviewing files that changed from the base of the PR and between d6798b5 and 4170b3a.

📒 Files selected for processing (1)
  • packages/query-core/src/queryClient.ts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

resetQueries method does not trigger refetch on errored queries

1 participant