retry failed request in the onResponse middleware

[pavlo-hadzheha]

Hello there! I've been trying to implement the refresh session functionality for quite some time using the response middleware.

The stumbling block is to retry the failed request inside the middleware. In the following code snippet, I am registering the Middleware and in the onResponse handler I'd like to add the retry line of the original request (look for the comment '// retry request here').

Any consultation would be greatly appreciated.

import { authService, TLoginResponse } from '@/shared/auth'
import { Middleware } from 'openapi-fetch'

let refreshPromise: Promise<TLoginResponse | undefined> | null = null

export const middleware: Middleware = {
  async onResponse({ response, request }) {
    if (response.ok) return response
    else {
      if (response.status === 401) {
        try {
          if (!refreshPromise) {
            refreshPromise = authService.refreshSession()
          }
          const refreshResponse = await refreshPromise
          if (refreshResponse) {
            authService.setAccessToken(refreshResponse)
            authService.setRefreshToken(refreshResponse)

            request.headers.set('Authorization', `Bearer ${refreshResponse.accessToken}`)
            try {
              return // retry request here
            } catch (innerError) {
              if (innerError.status === 401) {
                throw innerError
              }
            }
          }
        } catch (error) {
          authService.setRefreshToken({ refreshToken: null })
          authService.setAccessToken({ accessToken: null })
        } finally {
          refreshPromise = null
        }
      }
    }
  },
}

[pavlo-hadzheha]

I thought of an ability to call the coreFetch function with fetchOptions passed to the original request.

export const middleware: Middleware = {
  async onResponse({ response, request, originalFetchOptions, schemaPath }) {
    client.coreFetch(schemaPath, initialFeatchOptions)
 }
}

or

export const middleware: Middleware = {
  async onResponse({ response, request }) {
    client.coreFetch(request)
 }
}

Both imply that the coreFetch function would have to be returned from the createClient initializer and the latter implies that the coreFetch would handle the first parameter by branching using the following condition

if (schemaPath instanceof Request) {
  ...
} else {
  ...
}

[pavlo-hadzheha]

Let me know if it makes any sense at all. Or, perhaps, there are easier ways to achieve this w/o making changes to the source code. Thanks!

[pavlo-hadzheha]

I've got one more idea and it's to use native fetch just like this. Are there any potential problems with this I need to be aware of?

import { authService, TLoginResponse } from '@/shared/auth'
import { Middleware } from 'openapi-fetch'

let refreshPromise: Promise<TLoginResponse | undefined> | null = null

export const middleware: Middleware = {
  async onResponse({ response, request }) {
    if (response.ok) return response
    else {
      if (response.status === 401) {
        try {
          // ...

          if (refreshResponse) {
            // ...

            try {
              return fetch(request)
            } catch (innerError) {
              if (innerError.status === 401) {
                throw innerError
              }
            }
          }
        } catch (error) {
          // ...
        } finally {
          refreshPromise = null
        }
      }
    }
  },
}

[drwpow]

Yeah the difficulty you’re facing is that openapi-fetch’s API is designed to be 1:1 with requests. Middleware doesn’t really have the idea of persisting across multiple requests, or even retrying, with the thinking that the next level up from openapi-fetch is the layer handling that.

We had a previous issue that proposed this idea. But that was almost a year ago, and we’ve gotten more insights into how people do/don’t want to consume this library, and whether or not they’re using it with other wrappers such as TanStack Query, etc. There is currently somewhat of a split between folks who would like it to be a more robust, full-featured library, vs people who want to use it as a thin-as-possible typed fetch API wrapper. Your usecase falls under the former, currently.

But all things said, I do really like your suggestion to return coreFetch as part of the middleware API (or whatever it’s called). That could be a nice, lightweight way to give you a workaround for this, but without adding an additional layer of complexity. I think I also like this more than the original retry proposal because it would have fewer restrictions/assumptions on how it would be used.

I converted this to a discussion to allow for more informal conversation around this topic. But if this is a good workaround, please open another issue proposing adding coreFetch to the middleware API officially, and we can see to it that it makes it into a PR (whether by you, or another contributor)