supabase / supabase-swift / 36541039710

90%

push

github

fix(auth): discard a token refresh that outlived its session (#1374)

* fix(auth): discard a token refresh that outlived its session

A refresh that completed after `signOut` — and after another user signed in —
was applied to whatever session was stored at that moment. On success it wrote
the previous user's session back to storage and emitted `.tokenRefreshed` with
it; on a session-cleanup error code it deleted the *new* user's session and
emitted `.signedOut`. Every sub-client resolves its token from that storage, so
a newly signed-in user's requests then carried the previous user's access token.

`signOut` never cancels an in-flight refresh, and `RetryRequestInterceptor`
retries POST, so a `/token` retry can be created after `/logout` has revoked the
token — making the cleanup-error path the certain outcome rather than a rare one.

Guard both mutation sites with a storage snapshot taken before the request:

- `LiveSessionManager.refreshSession` reads storage before any suspension point
  and throws the new `AuthError.refreshDiscarded` instead of committing, if that
  session was cleared or replaced while the request was in flight.
- `APIClient.send`/`handleError` take the session a request was issued for and
  only run session cleanup while that session is still the stored one. This is
  the shared error path for every auth request, so an authorized call in flight
  during a sign-out can no longer sign out whoever signed in after it.
- `inFlightRefresh` is keyed by the refresh token it was started for, so a
  refresh asked for a different token is no longer served another one's result.

The comparison is between two storage reads, not between the caller's input and
storage: `setSession(accessToken:refreshToken:)` refreshes an externally-sourced
token with nothing stored yet, which is a legitimate hydration. This mirrors the
commit guard in supabase-js's `_callRefreshToken`. Swift needs no equivalent of
its `_sessionRemovalEpoch` — the storage acce... (continued)

49 of 49 new or added lines in 3 files covered. (100.0%)

10764 of 12024 relevant lines covered (89.52%)

893110.18 hits per line