Why does 400/401 trigger onSuccess?

[JamesBrightman]

I am calling a POST API using react-query and fetch. When the fetch returns a 400 or 401 error I expect the onError method to fire as 400/401 are error codes. Instead onSuccess triggers - why is this? How do I make it so that 400 errors are handled by onError?

Example code;

export const postExample = async ({ csvData, token }) => {
    const url = XXXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXX";

  const response = await fetch(url, {
      method: "POST",
      headers: {
          "Authorization": `Bearer ${token}`
      },
      body: csvData
  });
  console.log(response.status) //400
}


const [mutatePostExample , {isLoading, isError, isSuccess, data, error, status}] = useMutation(postStaffExceptions, {
        onSuccess: () => {console.log(data)}, //undefined - This is printed on 400 errors
        onError: () => {console.log(error)}
    });

...

 mutatePostExample ({csvData: file, token: "TOKEN_HERE"});

[TkDodo]

This seems to be a common misconception with fetch: fetch does not fail the promise with status codes >=400. Axios does this per default, but fetch does not. fetch only fails / throws on network errors. It's the most prominent difference between the two, and the reason why most people write a custom wrapper around fetch, or use redaxios or so, which is fetch with the axios api.

react-query expects you to return a failed promise, then it will go to error state. So you'd have to manually throw if (!response.ok)

[JamesBrightman]

Thanks for the reply, I see it's a fetch quirk that I didn't understand.

Out of interest what's a smart way to manually fail the promise?
I've just gone for if (!response.ok) throw Error; for now, but I'm not sure that does the job fully.

[TkDodo]

throw error is fine, Promise.reject(new Error(...)) is a bit more explicit imo

[mariotacke]

For those looking for a way to handle 401 responses globally, this is what I use to clear out a session and redirect back to login:

First, the retry function is set in a way that 401 responses are not retried. Any other response code falls back to the default behavior. (From what I can tell, the default 3 retry constant is not exposed, looking for feedback to improve). This triggers the onError function immediately which then checks for 401 again and performs any clean up before redirecting (ex: clear out session store, tokens, etc).

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      // @ts-ignore err: unknown -> err: AxiosError
      retry: (failureCount, err: AxiosError) => {
        if (err.response?.status === 401) {
          return false; // do not retry, trigger error
        }

        // otherwise, restore default
        const defaultRetry = new QueryClient().getDefaultOptions().queries?.retry;

        return Number.isSafeInteger(defaultRetry)
          ? failureCount < (defaultRetry ?? 0)
          : false;
      },
      // @ts-ignore err: unknown -> err: AxiosError
      onError: (err: AxiosError) => {
        if (err.response?.status === 401) {
          // clean up session state and prompt for login
          // ex: window.location.reload();
        }
      },
    },
  },
});

[conduct0]

Hi!
Thank you for this, it worked till the last update, I am now in 5.18.1.

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: (failureCount, err) => {
        if (err.response?.status === 401) {
          console.log('This works')
          return false; // do not retry, trigger error
        }

        // otherwise, restore default
        const defaultRetry = new QueryClient().getDefaultOptions().queries?.retry;

        return Number.isSafeInteger(defaultRetry)
          ? failureCount < (defaultRetry ?? 0)
          : false;
      },
      onError: (err) => {
        console.log('this doesnt work')
        if (err.response?.status === 401) {
          // clean up session state and prompt for login
          // ex: window.location.reload();
        }
      }
    }
  },
})

Above I added some console.logs to test and even though I manage to catch the error in the retry function, the callback for onError is never called. Did you or someone else experience this change?

Then I tried the following change:

{...
throwOnError: (err) => {
  console.log('this works')
  if (err.response?.status === 401) {
    // clean up session state and prompt for login
    // ex: window.location.reload();
  }
}
...}

This does seem to work. I decided to try this because of the migration doc
My best guess is that they changed the API, using this feels a bit obscure so I guess will stick with axios intercept.

[ribrewguy]

I believe there are still some odd behaviors related to OPs post. I have a fetch that returns a 400. I wrote a fetch wrapper that when the 400 is encountered, it returns a Promise.reject. However, this seems to cause useMutation to throw a hard error which needs to be caught with a try/catch. Is that expected? Because I expect to be able to use the isSuccess/isError/error/etc properties to determine what happened rather than having to wrap all calls to useMutation in try/catch blocks. Yes, I have set throwOnError to false with no change in behaviour.

[TkDodo]

please show a minimal reproduction because as you've described it, that should just work (if you're using mutate - try/catch is needed for mutateAsync)

[Asinging]

This works greatly. Thank you so much!!!
`const queryClient = new QueryClient({
defaultOptions: {
queries: {
retry: (failureCount, err) => {
if (err.response?.status === 401) {
console.log('This works')
return false; // do not retry, trigger error
}

    // otherwise, restore default
    const defaultRetry = new QueryClient().getDefaultOptions().queries?.retry;

    return Number.isSafeInteger(defaultRetry)
      ? failureCount < (defaultRetry ?? 0)
      : false;
  },
  onError: (err) => {
    console.log('this doesnt work')
    if (err.response?.status === 401) {
      // clean up session state and prompt for login
      // ex: window.location.reload();
    }
  }
}

},
})`