Disabled queries (enabled: false) get affected by invalidateQueries (refetchInactive: true)

[nikkizol]

Describe the bug

queryClient.invalidateQueries(queryKey, { refetchInactive: true, })
also refetches disabled queries (enabled: false)

but - #947 (comment)

looks like this issue was introduce in this commit - f5ae636

Your minimal, reproducible example

https://codesandbox.io/s/quiet-dust-hegny?file=/src/App.js

Steps to reproduce

1. Create a query with useQuery and set enabled option to false.
2. Invalidate this query with invalidateQueries and set refetchInactive to true

Expected behavior

I expected that disabled queries (enabled: false) would not refetch when I use invalidateQueries

Platform

• OS: macOs
• Browser: Not related

react-query version

v3.34.8

TypeScript version

v4.2.2

[TkDodo]

Thanks for filing the issue. It seems that a query is considered active` if it has at least one observer that is not disabled. From that definition, it follows that a a query is inactive if it has:
a) no observers or
b) only disabled observers.

In your case, b) would apply, which is why it is refetched. I've traced it back and it works the same as in v 3.2.0 (the first v3 release), so this is not a regression introduced recently.

However, I think this is wrong and it contradicts the docs where it says:

When enabled is false:
The query will ignore query client invalidateQueries and refetchQueries calls that would normally result in the query refetching.

From what I am seeing, the only check we should be doing is check a) it has no observers. Especially because enabled: false is often used when a query is not ready to be fired, like when a dependency is missing (dependent queries).

To be on the safe side, I would still suggest to fix this with v4, where we have also changed the queryFilters.

[Utsavojha2]

adding { exact : true } prevents refetching.
queryClient.invalidateQueries(["key2"], {
refetchInactive: true,
exact: true
});

[TkDodo]

adding { exact : true } prevents refetching.

no it doesn't, and it shouldn't. With your keys, there should be no difference between exact or fuzzy matching.

[Utsavojha2]

@TkDodo why do i get a throttled response with { exact: true }, but get successful response without it?

[TkDodo]

the api your sandbox queries against has rate limiting. Just use Promise.resolve instead!

[nikkizol]

@TkDodo do you have workaround on your mind for now?

[sualex]

+1 here. I've lost about 3 hours investigating why the query having {enabled: false} does fetch. The problem was invalidateQueries((q)=> ...).

[TkDodo]

@TkDodo do you have workaround on your mind for now?

use invalidateQueries without refetchInactive. Not sure in what case you would need inactive queries (queries that are not mounted) to refetch?

[nikkizol]

@TkDodo I found workaround for myself, but I hope this issue will be fixed in new version.

[tannerlinsley]

🎉 This issue has been resolved in version 4.0.0-alpha.9 🎉

The release is available on:

• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[tannerlinsley]

🎉 This issue has been resolved in version 4.0.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀