Handling authentication token refreshing with fetch interceptor

[jezzsantos]

I am trying to handle when any 401 is returned from any client request.
I am handling it in a response interceptor. I am only using fetch, not axios or any other client.

When this happens, I am calling my generated refreshToken() method, and if that succeeds I am attempting to retry the original request that failed with the 401.

My initial thought was to use use a new instance of fetch to make the original request to bypass the generated client.

To do that for a GET request is easy, but for a PUT, POST request, I need access to the original request's body, which has already been read!

If I continue to use fetch, how can I access the original request body, so that I can assemble the original request again, when it already failed?
(or is there another supported way of retrying the original request)?

[dosubot[bot]]

Hi @jezzsantos! I'm Dosu and I’m helping the openapi-ts team.

With fetch, request bodies (for PUT/POST) are streams and can only be read once, so you can't access the original body after the request fails unless you buffer it yourself. The openapi-ts fetch client exposes the original request in interceptors, but does not provide built-in retry or body preservation mechanisms docs.

To reliably retry requests after a 401, you need to preserve the request body before sending. The most common pattern is to buffer the body in memory (for example, as a string, Blob, or ArrayBuffer) and use that buffer for both the initial request and any retries. If you use JSON, keep the original object or string and pass it as the body each time.

Here’s a sketch of how you might do this:

client.interceptors.response.use(async (response, request) => {
  if (response.status === 401) {
    await refreshToken();
    // If you buffered the body before, you can reuse it here:
    const retryRequest = new Request(request.url, {
      ...request,
      body: request._bufferedBody // your custom property
    });
    return fetch(retryRequest);
  }
  return response;
});

client.interceptors.request.use((request) => {
  // Buffer the body before sending
  if (request.body && typeof request.body === 'string') {
    request._bufferedBody = request.body;
  }
  // For JSON, you could store the object or string
  return request;
});

If you use streams (like FormData or file uploads), you’ll need to buffer them as well, which can be tricky for large payloads. For most APIs, keeping the body as a string or object is enough.

This approach lets you retry the original request after refreshing the token, but be careful with large bodies and non-repeatable streams. For more details on interceptors and client config, see the docs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[jezzsantos]

Thanks @dosu,
This is good awareness. Appreciate it.

A couple of questions:

1. The reason I am asking this question is that the original request can only be read once, but your solution does not clone the request before caching it.
2. Why would you not cache the body if there was one at all? It is not clear why you only cache a string body, and what to do with other kinds of bodies. Can you elobaorate.

[dosubot[bot]]

Great questions!

1. With fetch, the request body is a stream and can only be read once. If you want to retry a request, you must buffer or clone the body before sending, because once fetch consumes it, it's gone. Cloning the Request object itself doesn't solve this unless you also clone or buffer the body.

2. The previous example only cached string bodies because strings (and plain JSON objects) are trivially repeatable—you can just reuse them. For other body types like Blob, FormData, ArrayBuffer, or ReadableStream, you need to explicitly buffer or clone them before sending. For example, you might keep a reference to the original Blob or FormData, or use arrayBuffer() to buffer binary data. ReadableStreams are the trickiest, since they can only be read once unless you implement your own buffering logic.

In short: always cache the body before sending, regardless of type. For strings/JSON, just keep the value. For Blobs, FormData, or ArrayBuffers, keep the original object or buffer. For streams, consider converting to a buffer or using a library to help with repeatability. This way, you can safely retry the request after refreshing the token. Be careful with large bodies and streaming uploads, as buffering can consume a lot of memory.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[jezzsantos]

Thanks again @dosu

Any reason why I couldn't/shouldn't do something like this:

Request Interceptor:

function cacheRequestBody(request: Request, _options: any) {
  const clonedRequest = request.clone();
  if (clonedRequest) {
    // @ts-ignore
    request._bufferedRequest = clonedRequest;
  }

  return request;
}

Response Interceptor:

async function handleUnauthorizedResponse(response: Response, request: Request): Promise<Response> {
  // Only handle 401s
  if (response.status !== 401) {
    return Promise.resolve(response);
  }

  return await refreshToken().then(async (res) => {
    if (res.response.ok) {
      const retry = await fetch(request._bufferedRequest);
      if (retry.ok) {
        return Promise.resolve(retry);
      } else {
        if (retry.status === 401) {
          logout().then(() => forceReloadHome());
          return Promise.resolve(response); // should never get here, this should bypass this error altogether
        } else {
          return Promise.resolve(retry); // This response will be different from the one passed into this interceptor.
        }
      }
    } else {
      if (res.response.status === 423 || res.response.status === 401) {
        logout().then(() => forceReloadHome());
        return Promise.resolve(response); // should never get here, this should bypass this error altogether
      } else {
        });
        return Promise.resolve(res.response); // This response will be different from the one passed into this interceptor.
      }
    }
  });
}

[dosubot[bot]]

There are a few caveats with this approach:

• Cloning a Request with .clone() only works if the body hasn't already been read. If the body is a stream (like a ReadableStream or some FormData/File uploads), it can only be read once. If the body has already been consumed by the time your interceptor runs, cloning will fail or result in an empty body.
• Not all body types are safely repeatable. Strings, Blobs, and ArrayBuffers are usually fine, but streams are not. If you need to support all body types, you should buffer the body yourself before sending the request, and reuse that buffer for retries.
• Attaching custom properties (like _bufferedRequest) to the Request object is technically possible in JavaScript, but it's not type-safe and could cause issues if other code expects a standard Request. A safer pattern is to keep a separate map of original requests to their clones or buffered bodies.
• There are no built-in utilities in openapi-ts or fetch for this; you have to manage buffering and retry logic yourself.

If you control all the requests and know their bodies are repeatable (e.g., always JSON or string), your approach can work. For maximum safety and compatibility, buffer the body before sending and store it outside the Request object, then reconstruct the Request for retries. This avoids surprises with non-repeatable bodies and keeps your code more robust.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[jezzsantos]

Thanks again,

I tried saving the request.body only, and tried assigning it to the new fetch request, but of course that does not work, since its a Readable stream. I guess, the @hey-api/open-ts library creates a readable stream even for simple JSON requests.

So, I need a way to save the ReadableStream as a buffer (as you say), and then figure out how to assign it back to a new fetch request.body somehow?

Any pointers on that first step?