interplay between auth-refresh & retry-exchange when internet is disconnected and request is made

[tom2strobl]

Hi there community!

I have a more general question I'd love to hear your feedback on:
I run an electron app where I'm using urql and it sometimes happens that when a user walks to their office and opens up their laptop my electron app is immediately trying to request new data for the day, even though an internet connection might not be up yet. This would be trivial since the retryExchange should cover that case: network error, retrying until network is up again and everything is fine. The issue is that more often than one would like to think a jwt expires before.

The docs lead me to believe that it's a best practice to leverage willAuthError to check if the token is expired and refreshAuth to then finally refresh the token.

The problem is, since the token expiry check in willAuthError is network-independent it will see that it's expired and run refreshAuth even though there is no internet connection, inevitably resulting in a fail. Now what I do in that case for safety reasons is to logout the user to avoid any corrupted state. From there without a connection the user is not able to login and with a connection everything is fine anyway.

Unfortunately for some users due to the timing of how slow their internet is connected after opening the laptop that means they have to log in everyday which is horrible UX I'm trying to fix.

Here's my authExchange and retryExchange:
(note that isJWTError and checkJWTIsExpired work fine and are omitted for brevity and that ensureAuthState either directly returns a jwt or fetches a new one using a refresh token)

function createAuthExchange(ensureAuthState: () => Promise<AuthState>) {
  return authExchange(async (utils) => {
    const newAuthState = await ensureAuthState()
    // note: this jwt needs to be refreshed
    // eslint-disable-next-line prefer-destructuring
    let jwt = newAuthState.jwt
    return {
      addAuthToOperation(operation) {
        // the token isn't in the auth state, return the operation without changes
        if (!jwt) return operation
        // leverage helper to append auth header
        return utils.appendHeaders(operation, {
          Authorization: `Bearer ${jwt}`
        })
      },
      // decipher from ALL errors, which were auth errors, so we can refresh properly
      didAuthError(error) {
        return isJWTError(error)
      },
      // checks before we even send the request if we need to refresh
      willAuthError() {
        // note: checkJWTIsExpired works in node and in the browser and is even sync
        if (jwt && checkJWTIsExpired(jwt)) {
          return true
        }
        return false
      },
      // in our case refreshing simply means calling ensureAuthState again
      async refreshAuth() {
        const refreshedAuthState = await ensureAuthState()
        // need to assign the new token to the outer jwt variable which will be picked up
        jwt = refreshedAuthState.jwt
      }
    }
  })
}

function createRetryExchange() {
  return retryExchange({
    initialDelayMs: 1000,
    maxDelayMs: 1000 * 60 * 5,
    randomDelay: true,
    maxNumberAttempts: 30,
    retryIf: (err) => {
      const isNetworkError = err.networkError
      return !!(isJWTError(err) || isNetworkError)
    }
  })
}

So long story short, is it in my case wise to simply remove willAuthError? In my head that would mean that even if a jwt is expired (the app wouldn't know that yet) before an internet connection is up it will always just network error which will be retried by the retryExchange until internet is back up and then it would didAuthError with the expired jwt and cleanly refresh the token.
Or is that a bad idea due to some internals?