async retry

[scr2em]

HI,

in my old project I was making an Axios interceptor and queuing all failed requests then fetch and refresh my refreshToken then retry all the failed requests.
with React Query I don't need half of the setup i made before (thanks React Query <3)
but now I'm stuck with the refreshToken mechanism as I want to move it to React Query instead of Axios Interceptor

as the docs say in useQuery options

retry: boolean | number | (failureCount: number, error: TError) => boolean

I think it would be a good idea to use async function for retry what do you think about this ?

  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        // query options
        retry: async (count, error) => {
          const {status} =error.resposne
                if (status && [401, 403].includes(status)) {
                      return await refreshAuthToken()
                  }
          return false // and redirect to login
        },   
    },
  })

[sred907]

Hi i am also looking for this sort of behaviour. But I would like to handle this at a global level. Is it possible?
eg: for any failed request I want to fetch refresh token and retry the failed call again.

[TkDodo]

I'm not opposed to this, just need to wrap my head around it completely.

1. You would need to return a Promise<boolean>, right? So the example would need to be something like:

        retry: async (count, error) => {
          const {status} = error.resposne
                if (status && [401, 403].includes(status)) {
                      await refreshAuthToken()
                      return true
                  }
          return false
        }, 

2. what is await refreshAuthToken doing? Is it writing the auth token somewhere where the queryFn will then pick it up?
3. what happens if the refreshAuthToken request fails? We would get a rejected promise, which we would likely interpret as "no retry" ?
4. currently, you can do all of this inside the queryFn. Is that so bad?

useQuery(key, async () => {
  try {
    const { data } = await axios.get(...)
    return data
  } catch(error) {
    const {status} =error.response
    if (status && [401, 403].includes(status)) {
      const token = await refreshAuthToken()
      const { data } = await axios.get(token, ...)
      return data
    }
    throw error
  }
})

I get that if we want this globally, we'd need to use the defaultQueryFn.

[damianbeles]

@bennettdams how did you solve the problem?

[bennettdams]

@damianbeles I'm still happy with my mentioned solution above.

[ammar-madni]

@tom-sherman Am I correct in assuming that you don't make the request to refresh your access token via a tanstack-query mutation? My setup sounds a lot like what you've suggested but I've not found a way to make it work with a mutation, this is because as soon as I wrap it in a mutation I can't await for the data from the response and then use the access token from the response to retry the original request that failed.

[tom-sherman]

Am I correct in assuming that you don't make the request to refresh your access token via a tanstack-query mutation?

Yes, that's right. We have a separate service that manages the token lifetime in memory. There might be a way to move this into RQ, but I could never figure it out.

[yeonah98]

Hello @TkDodo,

I've been exploring error handling mechanisms in the context of using React Query (tanStack Query) alongside Axios, and I'm particularly interested in understanding the best practices for utilizing React Query's onError callback in various scenarios.

When dealing with a 401 error, for instance, I understand that Axios interceptors are commonly used to catch and handle these errors globally. However, I'm curious about the specific cases where React Query's onError should be leveraged instead. Could you provide insight into when it's more appropriate to use onError within React Query for error handling, especially in situations that might not be adequately addressed by Axios interceptors?

Additionally, could you share examples of errors or situations during the fetching or mutation processes that are not caught by Axios interceptors and how React Query's onError can be effectively used to handle these cases? I'm looking to gain a deeper understanding of how to distinguish between errors that should be handled by Axios interceptors versus those that should be managed within the React Query framework.

Thank you for your guidance and insights😀

(with @okhan1998)

[arnaudbzn]

The approach is interesting to get rid of some logic inside the AuthenticationProvider I use to create to manage this problem.
To refresh tokens, I check access token expiration to be more precise about the need to refresh the token because a 401 can also mean that the access token is invalid or missing.
A 403 is an authorization error so it should not be related to a token expiration.

[arnaudbzn]

There is also a "proactive" solution if your access token is a JWT:
In your queryFn (your async fetcher), before calling your API, you can decode the jwt access token and check the exp claim.
So you can do const token = await refreshAuthToken() if the access token has expired (or soon to be expired).
You can even optimize the solution by storing the exp value in the query meta: so no need to decode the access token for each query.

[mwmcode]

Hi @TkDodo

Current retry function logic (typeof retry === 'function' && retry(failureCount, error)) will always evaluate to true if we pass async functions.

Can we make it so it throws (or at least fails) if retry is a function that does not return a boolean?

I was debugging why it wasn't acting as expected then came to realise that it doesn't support async fns.

// packages/query-core/src/retryer.ts
//...
        // Do we need to retry the request?
        const retry = config.retry ?? 3
        const retryDelay = config.retryDelay ?? defaultRetryDelay
        const delay =
          typeof retryDelay === 'function'
            ? retryDelay(failureCount, error)
            : retryDelay
        const shouldRetry =
          retry === true ||
          (typeof retry === 'number' && failureCount < retry) ||
          (typeof retry === 'function' && retry(failureCount, error))

can we change the last line to

(typeof retry === 'function' && retry(failureCount, error) === true)

I think a more DX friendly approach would check return type & throw if not a boolean

// ...check if retry true..number..
// ... check if it's of type function then
const retryFnResult = retry(failureCount, error);
if (typeof retryFnResult !== 'boolean') throw new Error("retry function must return a boolean")

[TkDodo]

It does error nicely for me with:

Type 'Promise<boolean>' is not assignable to type 'boolean'.

https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbzgVwM4FMCKz1QJ5wC+cAZlBCHAOQACMAhgHaoMDGA1gPRTr2swBaAI458VALAAoKWiyi8ACgDaVEhAhUAugBo4CgJRwAvAD44ABXIhgGAHQ9UEADYA3dAtXqq+3Qilw4Hhh8AC44elQ8RlY9Q1NEfwDA9BhkKEYLKxt0e3RHV3dgnH1EwilCfSA

[mwmcode]

Thanks @TkDodo
It must be an issue with my setup then.

[mwmcode]

This is getting spammy, sorry.

Just wanted to point out that it seems NOT to complain when you call useQuery with an object.

const result = useQuery({
  queryKey: ['foo'],
  queryFn: () => Promise.resolve('foo'),
  retry: async () => {
     Promise.resolve(true)
  },
})

https://www.typescriptlang.org/play?ssl=3&ssc=1&pln=4&pc=1#code/JYWwDg9gTgLgBAbzgVwM4FMCKz1QJ5wC+cAZlBCHAOQACMAhgHaoMDGA1gPRTr2swBaAI458VALAAoKawjN4PVMgA28ALwoM2XHgAUCKXDgidAaXR4AXHADaVEhAhUAugBpDx0XgBija7oBKODUAPjgABXIQYAwAOkUIZQA3dF17RyoA90kjHhh8a3pUPEZWOEDgsIMcoyNIihj0ePRURJTdfJwAj0Jswm7pSSA

Edit: or rather gives some different errors! ...idk... TS 😖

[TkDodo]

yeah it does complain, just differently, and very weirdly so:

    Argument of type '{ queryKey: string[]; queryFn: () => Promise<string>; retry: () => Promise<void>; }' is not assignable to parameter of type 'QueryKey'.
      Object literal may only specify known properties, and 'queryKey' does not exist in type 'readonly unknown[]'.(2769)

but I think this is because of our overloads and we'll get rid of them in v5. if we remove the overloads, the error is much better, see this playground.

    Type '() => Promise<void>' is not assignable to type 'RetryValue<unknown> | undefined'.
      Type '() => Promise<void>' is not assignable to type 'ShouldRetryFunction<unknown>'.
        Type 'Promise<void>' is not assignable to type 'boolean'.

[mwmcode]

I see it now. Thanks again.

This looks neat 👍 straight to the point. Excited about v5 already :)

[darshanatnintee]

Hey @TkDodo I tried async retry to refresh my token, Its stuck in infinite loop.

I did test this in v4 and rc

const retry = (count, error) => {
 if (count > 3) {
    console.log('WE ARE DONE WITH TRYYYYY')
  
  // this is not working 
    return Promise.resolve(false)
  }

  const axiosError = error as AxiosError
  const codeStatus = axiosError?.response?.status || 0

  console.log('CODE STATUS', codeStatus)

  if (codeStatus === 401) {
    console.log('GENERATING TOKEN')
    return Promise.resolve(false)
  }
  return Promise.resolve(true)
}
}

[TkDodo]

that's because retry isn't async.

[darshanatnintee]

Okay, it doesn't expect promise? Can we run async logic inside retry function?

[TkDodo]

no and no.

[darshanatnintee]

can I expect an async nature in the future?

[maapteh]

I also see a need for this but then on the hook level as well (not generic client). The current retry inside a hooks itself is currently only a number. But in our case 400 errors for example have explanations with key: FOO and we then decide what to do, but on 500 errors there can be some other error which we then simply want to retry, or really specific keys in 400 responses.

So my question basically is can we have a retry where we can act on the status code / error response.

[TkDodo]

you can already do that because reading a status code is not async ?

[fl0ydj]

We would need async retry for advanced error handling.
We are fetching data from the backend using useQuery and the data fetched influences code paths in useMutations. In case of stale data, this might lead to errors in the useMutation.

We are using websockets to invalidate queries to avoid staleness but in case of websocket timeouts, we want to have a backup invalidate mechanism if the usemutation throws specific error types. "Invalidation" here is not enough though and we actually need to await queryClient.refetchQueries which we can't do within the retry function.

We ended up wrapping the usemutation and usequery hook for now to add this to the query/mutation fn but its not ideal.