v5.85.2 introduced a breaking change while using StrictMode

[pvs-chainalysis]

Describe the bug

v5.85.2 introduced a breaking change while using StrictMode impacting state of isLoading and isFetching

On initial load state of isLoading doesn't reflect described API behaviour, API states that isLoading reflects the state of the first fetch, not subsequent fetches. However with StrictMode enabled isLoading reverts to false before the first request finishes

Example: https://stackblitz.com/edit/tanstack-query-2c4dbawu?file=src%2Findex.tsx

Example above updates DOM as request state changes: req1: isLoading:false, state: success, fetching: false data: request 1, time=1755607826585. time= is added when request is finished

Your minimal, reproducible example

https://stackblitz.com/edit/tanstack-query-2c4dbawu?file=src%2Findex.tsx

Steps to reproduce

1. On initial load observe that isLoading: true, state: pending and fetching: false
2. Observe isLoading quickly changes to false but state remains pending.

Before v5.85.2 isLoading would remain true until first request completes. If StrictMode is removed isLoading behaves as expected

Downgrade to 5.85.0 npm install @tanstack/react-query-devtools@5.85.0 @tanstack/react-query@5.85.0 and run the example again npm run dev and observe isLoading behaves as expected.

Expected behavior

At first load isLoading and isFetching should reflect the status of the first request.

How often does this bug happen?

Every time

Screenshots or Videos

Screen.Recording.2025-08-19.at.15.32.13.mov

Platform

• OS: macOS
• Browser: Chrome
• Version: 5.85.2

Tanstack Query adapter

None

TanStack Query version

5.85.2

TypeScript version

No response

Additional context

No response

[TkDodo]

Slight correction: It seems the behaviour first occurred in 5.85.2

[joseph0926]

This issue does not appear to be solely related to StrictMode, but rather occurs when using signal within the queryFn under StrictMode.
In fact, if you remove the signal from the provided code as shown below,

queryFn: () => {
  return new Promise((resolve) => {
    setTimeout(
      () => {
        const now = Date.now();
        console.log(`fetchCompleted index=${index}, time=${now}`);
        resolve(`request ${index}, time=${now}`);
      },
      4000,
      // { signal }
    );
  });
},

isLoading will correctly become true.

The problem arises because when the signal option is present and the fetch starts, destructuring the signal sets abortSignalConsumed = true

query/packages/query-core/src/query.ts

Line 428 in 7c464e3

this.#abortSignalConsumed = true

. Due to StrictMode, during cleanup the following condition is met inside removeObserver

if (this.#abortSignalConsumed) {
  this.#retryer.cancel({ revert: true });
}

query/packages/query-core/src/query.ts

Lines 351 to 352 in 7c464e3

	if (this.#abortSignalConsumed) {
	this.#retryer.cancel({ revert: true })

This triggers an asynchronous execution of this.#retryer.cancel({ revert: true }).
As a result, the sequence becomes: immediate re-mount → new observer added → second fetch begins → meanwhile, the asynchronous catch logic from the first fetch executes, which then hits the following branch

else if (error.revert) {
  this.setState({
    ...this.#revertState,
    fetchStatus: 'idle' as const,
  })
}

query/packages/query-core/src/query.ts

Lines 555 to 567 in 7c464e3

	} else if (error.revert) {
	this.setState({
	...this.#revertState,
	fetchStatus: 'idle' as const,
	})
	// transform error into reverted state data
	// if the initial fetch was cancelled, we have no data, so we have
	// to get reject with a CancelledError
	if (this.state.data === undefined) {
	throw error
	}
	return this.state.data
	}

This causes the state to be overwritten with the initial values, leading to the observed issue.

The reason it did not occur in the previous version is that onError existed and handled the case, but now the logic is fully asynchronous and falls into catch, which results in the problem you are seeing.