supabase / supabase-flutter / 39951497819

93%

push

github

fix(iceberg)!: parse Supabase error bodies, add timeout and abort, and stop swallowing config errors (#2038)

Linear:
https://linear.app/supabase/issue/SDK-2349/fixiceberg-parse-supabase-error-bodies-add-timeout-and-abort-and-stop

Also covers item 2 of https://linear.app/supabase/issue/SDK-2347
(`analyticsCatalog` ignores the request timeout), which that ticket
defers to this one, and adds the `analyticsCatalog` wiring test from its
item 8.

## Changes

Each item of the ticket, with its regression tests in
`packages/iceberg/test/iceberg_test.dart`:

1. **Supabase error bodies.** `IcebergApiException.fromResponse` now
also reads the Supabase Storage body (`statusCode`, `code`, `error`,
`message`): the message comes from `message`, `errorCode` from `code`
(falling back to `error`) and `code` from `statusCode`. Fields of the
Iceberg envelope with an unexpected type no longer throw a cast error.
2. **Timeout, abort and retry.** `IcebergRestCatalog` takes
`requestTimeout` (idle timeout through the shared `IdleTimeout`,
surfacing as an `IcebergNetworkException` caused by a
`TimeoutException`) and `retryOptions` (the shared
`SupabaseRetryOptions`, retrying network failures and `503`/`520` like
PostgREST, including a `503` whose body fails to arrive). Every
operation takes a `Future<void>? abortSignal`.
`SupabaseStorageClient.analyticsCatalog` forwards the storage client's
`requestTimeout`.
- A write generates its `Idempotency-Key` once and every retry repeats
it. Writes are only retried when the `/v1/config` response advertises
`idempotency-key-lifetime`. A server that ignores the key could apply a
repeated write twice, which is the 409-after-retry problem SDK-2347
describes for storage uploads. Reads are always retried.
3. **Config errors.** A failed `/v1/config` request now fails the
operation with the server's error instead of falling back to
`v1/<warehouse>`. The failure is not cached, so the next operation
fetches the config again. Concurrent operation... (continued)

1 of 1 new or added line in 1 file covered. (100.0%)

9606 of 10333 relevant lines covered (92.96%)

6.32 hits per line