Failed queries are automatically marked as stale.

[saby22]

I have a situation where I need to validate an user's refresh token upon visiting the web app.

The particular API call, can either fail or succeed.

However, I don't want the query to refetch on windowRefocus if it fails. React query automatically marks a query as stale if the API call fails even if staleTime is set to 'Infiinity', and refetches the query upon refocusing on the window.

I know this can be turned off, but is this the intended behaviour?

[TkDodo]

yes, this is the currently expected behaviour. queries that don't have data yet are always stale, so if it has an error but no data, it will be stale. You can have data and error at the same time if e.g. a background refetch fails.

We have a similar discussion here:

• The `refetchOn[Event]` options should accept a function #3110

would refetchOnWindowFocus: (data, error) => !!error work for you as well?

[saby22]

I think the refetchOn... functions accepting only query as a parameter is fine (unless I am missing some edge cases) , since query would already contain data as well as the status of the query.

  refetchOnWindowFocus?:
    | boolean
    | 'always'
    | ((
        query: Query<TQueryFnData, TError, TQueryData, TQueryKey>
      ) => boolean | 'always')

Passing data, query as well as error would be redundant.
@TkDodo what do you think?

[TkDodo]

yes, you can derive everything from query. query.state.data, query.state.error and query.status. However, wouldn't it be weird if all other options that can accept a value or a function that produces a value would get more than just the query (for convenience), like e.g. refetchInterval, which is:

  refetchInterval?:
    | number
    | false
    | ((
        data: TData | undefined,
        query: Query<TQueryFnData, TError, TQueryData, TQueryKey>
      ) => number | false)

the reason for that was that mostly, you'd want to calculate the interval from the response data, and the query is passed just in case you need more. The same goes for the global cache callbacks for example:

  onError?: (error, query) => void
  onSuccess?: (data, query) => void

they both take in what is more likely to be needed as first param, and the whole query second. I just want to avoid that every function has a different interface, as that is difficult to explain, especially for non-typescript users. But at the same time, I don't know what the first param should be for refetchOn 😅

[saby22]

Okay, I understand what you are trying to say.

In that case, keeping the first param as data is what I would lean towards, as it would be more uniform and easier for newer developers to understand. In that case, the docs should also mention/remind that the second query parameter has the other necessary states such as error and status

[TkDodo]

PR: #3518

[TkDodo]

merged it: https://github.com/tannerlinsley/react-query/releases/tag/v3.37.0