`isFetchedAfterMount` was broken in commit 1c8a921 / v5.87.1

[0xdiid]

Describe the bug

Hello!

It appears that isFetchedAfterMount was broken in 5.87.1 through that change inadvertently updating the dataUpdateCount. We're seeing behavior where the isLoading flag is set to false when data is loaded from cache, but since isFetchedAfterMount is inadvertently set to true too early we can't tell if that data was loaded from the server or from the cache. In essence, I believe that in cases where you are persisting data the isFetchedAfterMount flag might be entirely broken.

From Claude's analysis:

Root Cause Analysis

The commit 1c8a92167769f322d0206325b98493769afb0961 introduced logic that updates initialData when a Query exists without data. The issue is that when setData is called with manual: true, it increments dataUpdateCount from 0 to 1, even though this data wasn't actually fetched from the server but just set as initial data.

The Problem Flow:

1. Prefetch scenario: A query is created via prefetching (data is undefined, status is pending)
2. Observer mounts with initialData: When an observer mounts with initialData set
3. setOptions is called: The new code in query.ts:210-218 detects the query has no data and sets the initialData
4. setData with manual:true: This calls setData with manual: true, which increments dataUpdateCount from 0 to 1
5. queryInitialState capture: The observer captures the query state as #currentQueryInitialState with dataUpdateCount: 1
6. isFetchedAfterMount calculation: When calculated, it compares current dataUpdateCount (1) with initial dataUpdateCount (1), resulting in false initially, but any subsequent update makes it true prematurely

Your minimal, reproducible example

https://codesandbox.io/p/github/0xdiid/simple-is-fetched-repro/main?import=true

Steps to reproduce

Steps are in the repro app itself, but a quick copypaste here:

1. Click "1. Prefetch Query" - Creates query with undefined data, but starts fetching with a 3 second delay
2. Click "2. Mount Observer with initialData" - Triggers the bug (if pressed before 3 seconds)
3. If you clicked 2 before 3 seconds, you should see isFetchedAfterMount be true which is not expected
4. You can now click "3. Reset" to reset the state and wait for 3 seconds after clicking 1 to see flags set "properly"

Expected behavior

As a user, I expect isFetchedAfterMount to only trigger when the data is fetched from outside of the persisted cache, which matches previous implementations

How often does this bug happen?

Every time

Screenshots or Videos

Screen.Recording.2025-09-15.at.9.45.47.PM.mov

Platform

• OS: mac
• Browser: chrome
• Version: 140.0

Tanstack Query adapter

react-query

TanStack Query version

v5.87.1

TypeScript version

v5.9.2

Additional context

No response

[TkDodo]

yeah that seems legit. when initialData is applied, we should keep dataUpdatedCount to whatever it was (likely zero).

[TkDodo]

this might just mean instead of calling setData here:

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

Line 213 in a2151d2

this.setData(defaultState.data, {

we just do this.setState(defaultState) ? I think I didn't do that because it also puts the fetchStatus back to idle, which isn't what we want. setData with manual avoids this here:

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

Lines 644 to 648 in a2151d2

	...(!action.manual && {
	fetchStatus: 'idle' as const,
	fetchFailureCount: 0,
	fetchFailureReason: null,
	}),

So I think we need a middle ground between setData with manual and just setting the defaultState

Do you want to take a look at this?

[0xdiid]

I'm not sure I have enough context on the repo/lib as a whole to make a proper suggestion here, but it does seem at a glance the setData with manual and state.data being undefined would only be hit in this newly added edge case right? So you could just do something like this:

diff --git a/packages/query-core/src/query.ts b/packages/query-core/src/query.ts
index a34c8630d..8e85a75d3 100644
--- a/packages/query-core/src/query.ts
+++ b/packages/query-core/src/query.ts
@@ -636,7 +636,9 @@ export class Query<
           const newState = {
             ...state,
             data: action.data,
-            dataUpdateCount: state.dataUpdateCount + 1,
+            dataUpdateCount: action.manual && state.data === undefined
+              ? state.dataUpdateCount  // Don't increment for initial data
+              : state.dataUpdateCount + 1,
             dataUpdatedAt: action.dataUpdatedAt ?? Date.now(),
             error: null,
             isInvalidated: false,

That manages to pass tests, but again I'm not sure I have the full context to know if it would break other things.

[mihoward21]

@TkDodo any timeline on a fix here? Does the above proposal look good?

This is blocking us from updating the package, and we're now starting to miss out on other improvements. Would love to get this into a release soon.

[0xdiid]

Went ahead and put it up for review cc @mihoward21 @TkDodo

#9743