should it retry for 404 responses?

[raulingg]

By default when retry option is enabled (it is by default) react-query will retry to fetch whenever it gets an failed response from server, even when the status code is 404, which is a status code normally used when no data is found for the requested resource.

is this a normally behavior?

[tannerlinsley]

Yes it is. If you wish, you can use the retry option with a function to determine whether the error should result in a retry:

https://github.com/tannerlinsley/react-query#retries

[ched-dev]

I feel it should not retry if there is a 404. If it is 404, it's not there and therefor shouldn't try again.

[TkDodo]

you can definitely implement it like that with your custom retry function. I've just seen a use-case where someone fires off a mutation that creates a resource and then instantly re-directs to the new route, which yields 404 if the mutation takes some time. There, we want to retry as long as we get 404 :) Just pointing this example out to show that there are always different use-cases, and react-query tries to be as unopinionated as possible about them.

[HansBrende]

@TkDodo I was just about to disagree with you on your logic since it seems like the exceptional use-case should be implementing the custom retry logic, not the standard use-case of valid retry HTTP statuses (408, 502, 503, and 504).

But then I realized that your codebase is implementation-agnostic when comes to fetching frameworks (fetch, axios, etc.) and you'd have no way to actually KNOW what the status code is in the first place without making some assumption as to the shape of the error data!

So now I actually absolutely agree with you. Just not for the reason you stated.

[czabaj]

All of you who would like to implement some defaults for 404 are wrong, terribly wrong.

• the library cannot know the API you are calling, e.g. the API might not be REST, it might return 200 for all requests and disclose errors in payload, only you know your API and you can write your custom retry logic for that, it is easy.
• calling retry for 404 actually does make sense for some API - e.g. in eventually-consistent system there might be delay between the creation of the resource and it's availability, if you create resource and then query it immediately, it might return 404 and then after one second 200.

The library is not a holly cow and the world is more complex than you can imagine.

[igor9silva]

I feel like eventualy-consistent systems should need to implement a custom retry logic. For absolutely most use cases 404 should not retry (never).

But I understand that Query isn't attached to the network layer.

[unional]

When 404 is an acceptable result for a particular call, is there is way to suppress the error log?
I can use retry to adjust the behavior, but and error log is still being made.

[TkDodo]

Error logging will be removing in v5

[julien51]

I also believe the library should NOT retry by default on 4XX. Per the HTTP spec 4XX errors are client errors that indicate that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing).

The MDN website also has a clear indication that queries should NOT be repeated in that case.

@raulingg I would be happy to open a PR if you indicate here that it would be mergeable (in principle, and of course subject to all other requirements around tests, styling... etc)

[HansBrende]

@julien51 how would you suggest this library determine what the status code associated with the error is?

[denisborovikov]

Exactly. The query function can be any function returning a promise. It can be not even a network request.

[TkDodo]

@julien51 this is a common misconception about react query. It's not tied to data fetching. It needs a resolved or rejected Promise, that's all. Now some libraries do reject the Promise on 4xx status codes (like axios), and some don't (like fetch). It's entirely up to you.

[aakashsrdev]

Thanks for clarification @TkDodo @denisborovikov . Sometimes, just being always in use case for data-fetching, we tend to forget that it's not tied to data fetching.

[RodolfoSilva]

For anyone interested in a little snippet.

Example with axios.

import {QueryClient} from '@tanstack/react-query';
import {isAxiosError} from 'axios';

const MAX_RETRIES = 6;
const HTTP_STATUS_TO_NOT_RETRY = [400, 401, 403, 404];

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: (failureCount, error) => {
        if (failureCount > MAX_RETRIES) {
          return false;
        }

        if (
          isAxiosError(error) &&
          HTTP_STATUS_TO_NOT_RETRY.includes(error.response?.status ?? 0)
        ) {
          console.log(`Aborting retry due to ${error.response?.status} status`);
          return false;
        }

        return true;
      },
    },
  },
});

[jkazimierczak]

If anyone is using tRPC and searching for an equivalent to the isAxiosError then I recommend taking a look at: https://trpc.io/docs/client/vanilla/infer-types#infer-trpclienterror-types

[Dude29]

Thank you for this! 🙏

[divyam234]

For people using fetch

import {QueryClient} from '@tanstack/react-query';

const MAX_RETRIES = 6;
const HTTP_STATUS_TO_NOT_RETRY = [400, 401, 403, 404];

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: (failureCount, error) => {
        if (failureCount > MAX_RETRIES) {
          return false;
        }

        if (
          Object.hasOwnProperty.call(error, "status") &&
          //@ts-ignore
          HTTP_STATUS_TO_NOT_RETRY.includes(error.status)
        ) {
          console.log(`Aborting retry due to ${error.status} status`);
          return false;
        }

        return true;
      },
    },
  },
});