Conditional Retry

[julianwachholz]

I'd like to explore the possibility of adding a conditional retry feature.

One might not want to retry if the server responds with a 404, then we just want to display a "not found" page. But we still want to retry if there's a temporary error somewhere else.

[nikoskleidis]

If I understand correctly what you are trying to do, you can use retry option as described here:
https://github.com/tannerlinsley/react-query#retries

[julianwachholz]

Thanks for your input, I am using this setting but it doesn't allow conditional values as I've explained.

[nikoskleidis]

Then I think you should handle the 404 error internally (without throwing an error). You can throw an error only for status codes that you want react-query to retry fetching.

[julianwachholz]

You're right, I'm silly. Right now I'm just throwing when !response.ok, which might be a bit overzealous.

[tannerlinsley]

Let me know if there is any more to discuss here.

[smozely]

Don't know if I should raise a new issue or continue the discussion here ...

The idea for handling the errors internally doesn't work that well for using Suspense and Error boundaries.

What we thinking we want to do is have failed requests be sent up the error boundaries, and there we would have a error boundary that handles just the data being unavailable, and a boundary higher up the stack that handles more fatal things ... like session timeouts, which in our case need to send the user to our login application. And here a session timeout error would be something we don't want to retry on.

In a POC of writing our own lib for handling this type of stuff, we had a magic "NoRetryError" which would wrap a real error, that we would throw to indicate something shouldn't be retried, which worked ... but felt a little gross because it was the only time our fetching stuff needed to know it was being wrapped in our lib. Another thing we considered was adding a magic prop to an Error to indicate not to retry ... but has that same issue of needing to know its being wrapped.

[tannerlinsley]

So what exactly are you saying needs to happen?

[smozely]

So I think I need to be able to throw an error which tells react-query not to retry

Either ...

• A config function that can inspect the error and return true / false if it should be retried
• A NoRetryError type the the fetch can throw
• Adding something like .noRetry = true before the fetch throws

I'm thinking the config function might be best

[smozely]

Actually I've just looked at the code,

I think it would be easy to do the version of a config function. theres just that spot where it checks if it should retry, and there we can call the function, which can decide if its a retry-able error or not ... the default being true.

I'd be happy to submit a PR for that, as long as you don't think its a bad idea and would never merge it.

[julianwachholz]

The function to check if it should retry was my original thought to this as well.

[cherniavskii]

Implemented in #294

[TkDodo]

Sorry, not gonna happen. This needs to work:

useQuery({
  queryKey: ['answer'],
  queryFn: () => Promise.resolve(42)
}

there’s no http call, not status, no object returned. Just a number. If you want to return { data, headers, status } from your queryFn, that’s something your API layer / abstraction needs to do.

Then, you can implement retry by looking at data.status

[ciprianmacovei]

yes but the promise can return the response obj right ? u can enforce ppl to return the response obj not the data or whateva, because this library is made for reqests , a wrapper for req right ?

[ciprianmacovei]

and data will be the response obj, and can be destructed, i'm only proposing 😅

[TkDodo]

this library is made for reqests , a wrapper for req right ?

it’s for async state - we only enforce that a Promise must be returned. Doesn’t have to be an object with data property or whatever. If you think we can make a (breaking) change like that you’re grossly underestimating the impact that would have on millions of existing usages for little gain.

[ciprianmacovei]

yeah ur right