Sending error response from API sets response body as SWR data

[bwillem]

Given an error like this being sent from an express API:
res.status(500).send({ message: 'Message' })
Even while throwing in the fetcher, the response body ({message: 'Message'}) is still being set as data:
const { data } = useSWR(endpoint) // data should be undefined or a cached value, not the error response body

Am I missing something? Do I have to just not send a response body at all?

[koba04]

I think it depends on the implementation of your fetcher. If it's resolved as rejected, the return value of data would be undefined.
I've confirmed it by the following test.

  it('should not assign the error object to the data when an error occured', async () => {
    function Page() {
      const { data, error } = useSWR(
        'error-10',
        () => new Promise((_, rej) => rej({ message: 'error!'}))
      )
      if (typeof data === "undefined" && error) return <div>{error.message}</div>
      return <div>hello, {data}</div>
    }
    const { container } = render(<Page />)

    expect(container.firstChild.textContent).toMatchInlineSnapshot(`"hello, "`)
    // mount
    await screen.findByText('error!')
  })

[bwillem]

Thanks for taking the time to take a look, I appreciate it.

You're right, rejecting a promise in the fetcher sets that on error, not data. Your test doesn't include the piece that's breaking my experience - a response body (await res.json()). What i'm experiencing is the fetcher rejecting, but the response body still being set on data in the background, no matter if the fetcher throws or rejects. There's something built into SWR that assumes you want res.json() set on data, even if the status code of the response is an error, and even if you explicitly reject the promise in the fetcher. This means if you have some data cached, and the next request 401s for example, it replaces your cache with the error object (or whatever your server put in the response body). The way I'm solving it now is not sending anything with error responses, which sucks because my logs become "SWR fetcher error" with no context.

I'll have to do some experimenting. It seems a bit counter intuitive and might in fact be my fetcher implementation.

[bwillem]

Yea it was a me problem as usual 😆.
My fetcher comes from a context provider, the API call in question was outside of this provider, so SWR was defaulting to the stock fetcher.