retry function should also pass data

[fuddlesworth]

Many API's work as a job system that require querying until a status changes to a state that's not in progress. The best way to support this would be through the query retry as it already supports back off delay and such. The problem is retry only passes in failureCount and error. Having data passed into this function would be immensely helpful as we could then do something like this (assuming the API returns a status key)

retry: (data, failureCount, error) => {
   if (!error && data.status === 'FINISHED') {
        return false;
    }
    return true;
}

[TkDodo]

Many API's work as a job system that require querying until a status changes to a state that's not in progress.

This sounds more like you want the refetchInterval and maybe set your query to disabled if a certain status has been reached ?

As far as I know, retries only happen when there is an error. Otherwise, the default of "3 retries" would not really work. So if you want to use that, you would need to produce a failed promise somehow so that react-query can retry. You can either have your backend send a status code that produces an error, or you await the data in your fetch-function and then throw if your status is not 'FINISHED', which will then in turn trigger a retry with the error.

Passing data wouldn't solve this, because data will either be stale or undefined if an error happens. And, as I said above, I don't think we can invoke the retry function for successful queries.

[fuddlesworth]

This sounds more like you want the refetchInterval and maybe set your query to disabled if a certain status has been reached ?

No, I want to be able to utilize the exponential backoff and not make my own. Otherwise, that requires: 1) creating this function 2) storing the results in state

As far as I know, retries only happen when there is an error. Otherwise, the default of "3 retries" would not really work.

retry takes a function, boolean, or number. Meaning you can disable/enable retry, set it to a retry count like you said, or have custom logic based off the error and failureCount (potentially retrying forever if your logic is bad).

So if you want to use that, you would need to produce a failed promise somehow so that react-query can retry

This is why I opened a discussion. Many instances you have zero control over the backend. Many APIs also work in this job like manner.

Passing data wouldn't solve this, because data will either be stale or undefined if an error happens. And, as I said above, I don't think we can invoke the retry function for successful queries.

How would it be stale? Currently retry happens if an error is thrown. It can be made to be always called if retry is a function with the data passed from queryFn.

[TkDodo]

This is why I opened a discussion. Many instances you have zero control over the backend. Many APIs also work in this job like manner.

Yes, which is why I suggested to produce a failed promise in the fetchFn:

const queryInfo = useQuery('key', async () => {
  const { data } = axios.get(...)
  return data.status === 'finished' ? data : Promise.reject(data)
})

This seems like the easiest case imo.

How would it be stale? Currently retry happens if an error is thrown. It can be made to be always called if retry is a function with the data passed from queryFn.

If you successfully fetch data, and then you do a background re-fetch, which failes, react-query would maybe still give you the stale data (similar to how it gives you the stale data to the view).

I don't think it can be easily made to be always called if it is a function.

• It would add complexity: if it's a number or a boolean, it's only called on error, but for a function, it's always called
• it would be breaking, because I'm sure there are people out there that have implemented retry functions to only retry on certain errors, e.g. don't retry on status 400:

const queryInfo = useQuery('key', () => axios.get(...), {
    retry: (failureCount, error) => failureCount < 4 && error.status !== 400
})

Now you would get 3 retries for successful responses, or am I missing something?

[fuddlesworth]

This is why I opened a discussion. Many instances you have zero control over the backend. Many APIs also work in this job like manner.

Yes, which is why I suggested to produce a failed promise in the fetchFn:

const queryInfo = useQuery('key', async () => {
  const { data } = axios.get(...)
  return data.status === 'finished' ? data : Promise.reject(data)
})

This seems like the easiest case imo.

This is a hack in current functionality (which I'm wanting to avoid) to get around a fundamental use case in API design which I don't think you understand.

If you successfully fetch data, and then you do a background re-fetch, which failes, react-query would maybe still give you the stale data (similar to how it gives you the stale data to the view).

I don't think it can be easily made to be always called if it is a function.

• It would add complexity: if it's a number or a boolean, it's only called on error, but for a function, it's always called
• it would be breaking, because I'm sure there are people out there that have implemented retry functions to only retry on certain errors, e.g. don't retry on status 400:

const queryInfo = useQuery('key', () => axios.get(...), {
    retry: (failureCount, error) => failureCount < 4 && error.status !== 400
})

Now you would get 3 retries for successful responses, or am I missing something?

What??? That's the current design. Read the APIs. It just works on thrown errors which can easily be changed.

I would rather @tannerlinsley chime in as this is his library and he knows the ins and outs.