Query keeps retrying despite 'enabled' set to false

[alekseyrozh]

Describe the bug

This issue raised in the past - #1380 which is now marked as resolved, however I would want to highlight a usecase that doesn't look right.

function useApps(enabled: boolean) {
  const queryResult = useQuery({
    queryKey: ['apps'],
    queryFn: () => fetch(`/api/apps`),
    enabled: enabled,
  });
  return queryResult;
}

If the query starts, the first fetch fails, and then enabled turns to false due to some other reason, the fetch keeps being retried according to the retry policy. If in the end it still fails the queryResult will have an error status which will show up after all the retries are done. In my case with 3 retries ~15 seconds after enabled was set to false.

I presume adding enabled to query keys might help, but this feels wrong and also kind of contradicts the point of having an explicit "enabled" param.

queryKey: ['apps', { enabled }],

Your minimal, reproducible example

https://codesandbox.io/p/devbox/magical-rubin-ryf6wt?workspaceId=ws_GqRnfu5ueZhkd8SSdfMDQo

Steps to reproduce

• Have a query which would fail
• Have an enabled param to it
• Set enabled to false while the query is being retried
• See this not taking any effect

Expected behavior

When enabled becomes false, the query should not be retried and the state should be whatever it was before this query started, aligning with this doc

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

Browser: Arc

Tanstack Query adapter

None

TanStack Query version

5.54.1

TypeScript version

5.5.4

Additional context

No response

[TkDodo]

When enabled becomes false, the query should not be retried

enabled decides if the query should run / start or not. It is not checked again between retries, as retries are an opaque process. As the linked issue suggests, you can set retry to a function to check if you want to perform retries or not.

aligning with this doc

That doc doesn’t say anything about retries. It says that “The query will not automatically fetch”, which is true, but it refers to “starting a fetching process”, which starts with the first invocation of the queryFn and ends after all retries have been done.

You can also see that in between retries, the query doesn’t change it’s primary state. It will stay in status: 'pending' and fetchStatus: 'fetching'. It will only transition to status: 'error' after all retries have been done.

[alekseyrozh]

hi @TkDodo, thanks for jumping in!

I attempted to set retry to a function ->

    retry: (failureCount, error) => {
      if (!enabled) {
        return false;
      }
      if (failureCount >= 3) {
        return false;
      }
      return true;
    },

However enabled in the retry() function is not changing its value, you described a similar behaviour in the older thread. Which to me sounds there's no way to stop retries once they started?

What i am trying to achieve is for the query to stop fetching and just keep the current value once my flag (in this case the enabled that I pass into my hook) is set to false, is there a mechanism for this?

[TkDodo]

However enabled in the retry() function is not changing its value

yeah that’s how closures in JavaScript work.

What i am trying to achieve is for the query to stop fetching and just keep the current value once my flag (in this case the enabled that I pass into my hook) is set to false, is there a mechanism for this?

Probably cancelling the query imperatively with queryClient.cancelQueries() is what you want? What’s the use-case for having a query that a) has started, b) has failed, c) you want to retry and d) all of a sudden want to stop it ?

[alekseyrozh]

The use case is the following:

1. Query starts fetching, but happens to fail
2. App user performs an action that makes the query irrelevant - hence enabled is set to false
3. After all retries 10 seconds later the user sees an error screen which doesn't make sense anymore cause the query is disabled and is no longer relevant

I guess cancelling the query makes sense in this case, does it mean query cancelling should happen in all cases when enabled is set to false? What would be the use case where you don't want to cancel it?

[TkDodo]

enabled is an observer property, you can have different observers (useQuery “instances”) where one is enabled and the other is disable. enabled: false just means that this observer won’t trigger a fetch, it doesn’t have an influence on running fetches, as they might have been triggered by something else entirely.

for example, you might have a queryFn running and while that happens, you mount a disabled observer that essentially just “reads” data, but doesn’t fetch any on its own. At this point, we wouldn’t want to cancel the queryFn.

So, the best thing you can do is call queryClient.cancelQueries at point 2 where the user performs the action that makes the query irrelevant. You can also unmount the part that makes the query irrelevant, which would trigger an automatic cancellation if you opt into the provided AbortSignal.