Errors for shared queryKeys cause all queryFn to run, even if disabled

[C3ntraX]

Describe the bug

I found a issue regarding shard queryKeys and errors within queryFn's.

If you run one useQuery which causes an error, all other queries will also be running and even ignoring the enabled: false state.

I don't know, how this would even work, if both queries will result without error? I think, it don't make sense at all, that queryFn are running for errors of other queryFn.

So there might be multiple issues to solve here...

  const { refetch } = useQuery({
    queryKey: ["key"],
    queryFn: async () => {
    .... 
    throw new Error(...)
    },
    enabled: false,
  })
  
  .... 
  refetch()
  ....

  const { isSuccess, isError, error } = useQuery({
     queryKey: ["key"],
    // <--- Tries to run queryFn
    enabled: false,
  })

Your minimal, reproducible example

https://codesandbox.io/p/sandbox/practical-morse-s8xjcc?file=%2Fsrc%2FApp.js%3A40%2C6

Steps to reproduce

1. Click refetch
2. Wait for the error --- false true Error: error
3. Click refetch
4. Wait for the error --- false true Error: Missing queryFn: '["key"]'
5. See that the second useQuery caused Missing queryFn: '["key"]' if you provide this queryFn then it will be executed ???

Expected behavior

• queryFn should not ignore the enabled state if multiple useQuery share the same key
• queryFn should only refetching on error for the queryFn who actually caused the error and not running all queryFn's with the shared key

How often does this bug happen?

Every time

Screenshots or Videos

Platform

Windows

Tanstack Query adapter

react-query

TanStack Query version

5.28.14

TypeScript version

5*

Additional context

I just want to grab the shared variables

[TkDodo]

1. refetch returned from useQuery is the only thing that bypasses enabled.
2. There really shouldn't be different queryFns for the same queryKey. The two always go together - the key defines the dependencies for the function.

I just want to grab the shared variables

I'm moving this to a discussion since I think you're just trying to achieve something with enabled: false + different queryFns that shouldn't really be necessary. Maybe we can help if you can outline what problem you're actually trying to solve?

[TkDodo]

there is no refetch:false option.

I would need to know why you think you need queries with enabled:false in the first place (it's usually not the best pattern) and why you additionally want a query with the same key but without the queryFn. I'm pretty sure you don't want that, you're just doing this because it's you thinking it's the best way to get where you want to go. But it's not. So without you telling me where you want to go, I can't tell you how you would idiomatically solve your problem. So please just tell me the use-case of the answer will be: "this doesn't work", end of story :)

[C3ntraX]

Okay here is my problem:

Calculation of the actualy results in a own listing-tool-handler.tsx as workaround, since #6840 is still the problem. But even then, I don't want to grab the variables out of the useQuery since its much really much overhead

const groupedItemsResults = useQueries({
    queries: stashes
      ? stashes.map((stash) => {
          return {
            queryKey: [currentUser?.profile?.uuid, 'stash', league, stash.id],
            queryFn: async () => {
              ... do stuff
            },
            enabled: false
          }
        })
      : []
  })

Deeply nested component somewhere (not even a direct child)

const { isSuccess, isError, isFetching, dataUpdatedAt } = useQuery({
    queryKey: [currentUser?.profile?.uuid, 'stash', league, stash.id],
    queryFn: async () => {
      await Promise.reject({ ignore: true }) <--- current workaround, I'm not satisfied with it
    },
    enabled: false
  })

[TkDodo]

• why do they all have enabled: false?
• why can't you use the same queryFn in the deeply nested component that you use above?

Example:

export const itemOptions = (currentUser, league, stash) => queryOptions({
  queryKey: [currentUser?.profile?.uuid, 'stash', league, stash.id],
  queryFn: () => do stuff ...
})

const groupedItemResults = useQueries({
  queries: stashes ? stashes.map(stash => itemOptions(currentUser, league, stash)) : []
})

in nested component:

const { isSuccess, isError, isFetching, dataUpdatedAt } = useQuery(
  itemOptions(currentUser, league, stash)
)

[C3ntraX]

Hey :)

why do they all have enabled: false

Okay, so I process groupedItemsResults and get all refetch functions as refetchAll from the object. I call this function imperatively with a button click.
So working with enabled true/false doesn't work because the data has to be queried fresh and cannot be cached. But only with a button press.

In reality, I have several useQueries connected in series that make further requests based on the return values.

why can't you use the same queryFn in the deeply nested component that you use above?

I'm not allowed to fire multiple requests for the same key to the server at the same time because I have to be careful with ratelimiters or I'll get high time penalties. That's why I get my own 429 as an error with the waiting time for when the next retry can take place. The server is a proxy server for some endpoints for the actual api.

I just don't understand why the same request should be fired multiple times. If I pass the queryFn everywhere, it would execute the same request multiple times, which can lead to ratelimiter problems. The design pattern doesn't work in my head. Just some feedback.

BR

[TkDodo]

I call this function imperatively with a button click.

Most often, what you want is lazy queries where enabled is a dynamic condition. Have a look at this example from the docs: https://tanstack.com/query/v5/docs/framework/react/guides/disabling-queries#lazy-queries

I'm not allowed to fire multiple requests for the same key to the server at the same time

React Query automatically deduplicates requests going out at the same time. If the query from the nested component would fire while the query from the useQueries from higher up the tree would fire, it would just pick up the running promise.

Most likely, you're seeing another request after the first one has already finished. The recommendation is to set a staleTime to define the time frame in which data is considered fresh and data will only be read from the cache if available, without triggering a refetch. If you only want to ever fetch a resource once, set staleTime: Infinity.