supabase / supabase-flutter / 35998092270

94%

push

github

feat(supabase): surface the server request id on exceptions (#1885)

Every response from the Supabase gateway carries an `sb-request-id`
header, but nothing in the SDK exposed it. A user with a failing request
had no identifier to paste into the log explorer or quote in a support
thread.

Adds `requestId` to `SupabaseException`, so `AuthException`,
`PostgrestApiException`, `StorageException` and `FunctionException` all
carry it, and every `toString` lists it. The value is read off the
response headers in each client's error path: `sb-request-id` first,
`x-request-id` as the fallback for a self-hosted stack behind a reverse
proxy that assigns its own. It is `null` when no response was received
or the response carried neither.

Beyond the service error responses, the id is also set on the exceptions
a client raises after receiving a response: the auth
`AuthUnknownException`, the postgrest exceptions for a non-JSON 2xx body
and for the row `maybeSingle()` rejects, and the storage exception for a
success body of the wrong shape. `AuthException` equality includes the
new field. `PostgrestApiException.toJson` and both `fromJson` factories
carry it too.

Successful responses do not expose the id. Most calls resolve to the
decoded data rather than a response object, so exposing it there would
mean a new wrapper type on every method for a value that is only needed
once something has gone wrong.

`sdk-compliance.yaml` is unchanged: the field is declared on the shared
base in `supabase_common`, which the symbol scan excludes, and the
service exceptions only inherit it. The compliance validation, the
public API symbol check and the drift check pass locally against the
pinned tooling. No canonical capability exists for request ids yet.

Verified against two hosted projects that the REST, auth, storage and
functions endpoints all answer with `sb-request-id`.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Ne... (continued)

30 of 30 new or added lines in 10 files covered. (100.0%)

8696 of 9542 relevant lines covered (91.13%)

4.89 hits per line