A call to fetchQuery is cancelled when React useQuery is unmounted

[bartlangelaan]

Describe the bug

While integrating Tanstack Query with another library, I found queryClient.fetchQuery() to fail the first time during development. The promise was cancelled when some component was using the same query with useQuery - only during development, when using StrictMode.

But it can also happen in production. If an useQuery is unmounted, it cancels the query if it is the last one observing the query. Even if some other code is running queryClient.fetchQuery(). I would expect Tanstack Query to know that fetchQuery is running and not cancel the query.

Your minimal, reproducible example

https://codesandbox.io/p/sandbox/tanstack-query-issue-9798-fetchquery-cancelled-gkt869

Steps to reproduce

1. Open the codesandbox
2. The useQueryResult will succesfully show the amount of stargazers, but the fetchQueryResult will contain a CancelledError.

Expected behavior

As a user, I expected the fetch not to be cancelled because fetchQuery was called. I would expect that unrendering a useQuery call would not in any way influence a call to fetchQuery anywhere in the application.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: Linux, Mac
• Browser: Edge, Chrome 141.0.7390.76

Tanstack Query adapter

react-query

TanStack Query version

v5.90.5

TypeScript version

No response

Additional context

No response

[bartlangelaan]

I have one additional example, which is not using strictmode. The query is cancelled after two seconds: https://codesandbox.io/p/sandbox/tanstack-query-issue-9798-fetchquery-cancelled-without-strictmode-2xcsfm

[DogPawHat]

which library are you trying to integrate with and is it open source?

[DogPawHat]

I took a closer look at your sandbox and made a slight change here to track when things run https://codesandbox.io/p/devbox/tanstack-query-issue-9798-fetchquery-cancelled-forked-p93k2t

basically, the abort signal will always be false while there are no observers, so if you run fetch query and use the signal it will abort. however by default the signal isn't used and if it wasn't' using signal it would complete and populate the cache. (https://tanstack.com/query/latest/docs/framework/react/guides/query-cancellation#default-behavior)

so we'd have to change the semantics of that abort signal to make an exception for fetchQuery if it's imperative. I'm not sure that's what we want.

[TkDodo]

I don’t think that’s what we want, the behaviour is definitely on purpose. If you use fetchQuery in a route loader, you will most likely await it. If you don’t await it, it doesn’t matter that it fails.

It’s also only relevant if you opt-in to the abort signal - the default behaviour is to not cancel the request, so this is fine.

I think I actually added a test-case lately to make sure the fetchQuery result resolves with a CancelledError here, because before that, we would just hang indefinitely:

query/packages/query-core/src/__tests__/queryClient.test.tsx

Lines 1036 to 1063 in e4f5ce8

	test('should throw CancelledError for imperative methods when initial fetch is cancelled', async () => {
	const key = queryKey()
	const promise = queryClient.fetchQuery({
	queryKey: key,
	queryFn: async () => {
	await sleep(50)
	return 25
	},
	})
	await vi.advanceTimersByTimeAsync(10)
	await queryClient.cancelQueries({ queryKey: key })
	// we have to reject here because we can't resolve with `undefined`
	// the alternative would be a never-ending promise
	await expect(promise).rejects.toBeInstanceOf(CancelledError)
	// however, the query was correctly reverted to pending state
	expect(queryClient.getQueryState(key)).toMatchObject({
	status: 'pending',
	fetchStatus: 'idle',
	data: undefined,
	error: null,
	})
	})
	})

[bartlangelaan]

which library are you trying to integrate with and is it open source?

I am using MUI X Tree View, following this example: https://mui.com/x/react-tree-view/rich-tree-view/lazy-loading/#using-react-query

however by default the signal isn't used and if it wasn't' using signal it would complete and populate the cache.
It’s also only relevant if you opt-in to the abort signal - the default behaviour is to not cancel the request, so this is fine.

While that is of course true, in this case I am using Orval which auto-generates queries based on an openapi specification. It consumes the signal by default, which is of course what you want in 99% of the time.

I still think its very weird that doing a fetchQuery produces different results if some other component is using useQuery to fetch the same query. It took a long time of debugging before I figured out why my query was sometimes cancelled..