supabase / supabase-swift / 32133071164

87%

Build Type

push

github

Committed by web-flow

Commit Message

fix(supabase): propagate access-token provider errors instead of swallowing them (#1236)

* fix(supabase): propagate access-token provider errors instead of swallowing them

`adaptRequest` converted any error from resolving the access token — including
one thrown by a configured `options.auth.accessToken` third-party auth
provider — into `nil` via `try?`, so the request would silently go out under
the anon key instead of failing. Only `AuthError.sessionMissing` (no signed-in
user, the expected case) should fall back to the anon key; every other error
(a network failure refreshing the session, or a throwing custom `accessToken`
provider) must fail the request instead of downgrading it to an anonymous one.

Flagged by CodeRabbit on #1233, and cross-checked against supabase-js and
supabase-flutter, both of which already propagate these errors rather than
swallowing them (flutter's `AuthHttpClient` explicitly documents this: "Throw
the error instead of making an API request with an expired token"). Also see
supabase/sdk#86, which corrects the capability spec to match.

* refactor(supabase): move sessionMissing handling into accessTokenProvider

Per @spydon's review on #1236: `adaptRequest` shouldn't need to know which
auth errors are benign. Move the `catch AuthError.sessionMissing` into
`accessTokenProvider` itself, so every caller — `adaptRequest` and the
Realtime `accessToken` closure via `_getAccessToken()` — gets the same
"no session falls back to nil, everything else propagates" behavior for
free, instead of each caller needing its own catch. The Realtime closure
previously had no such handling at all, so this also fixes it falling
back consistently with REST/Storage/Functions.

Coverage Stats

7 of 9 new or added lines in 1 file covered. (77.78%)

7 existing lines in 1 file now uncovered.

8340 of 10477 relevant lines covered (79.6%)

33.37 hits per line