supabase / supabase-flutter / 39979930520

94%

push

github

fix(supabase)!: make stream() survive reconnects without losing or corrupting rows (#2028)

Resolves
[SDK-2337](https://linear.app/supabase/issue/SDK-2337/fixsupabase-make-stream-survive-reconnects-without-losing-or).

`stream()` broke or showed wrong data around realtime reconnects. This
reworks the lifecycle in `SupabaseStreamBuilder`.

## Changes

1. **A failed fetch no longer ends the stream.** A transient failure is
retried with the realtime client's `reconnectAfter` backoff. While the
retry is pending, changes are applied to the previous snapshot if there
is one, so live updates keep flowing and nothing piles up in a buffer. A
client error that a retry cannot fix (a 4xx other than 401, 408 or 429,
such as a missing table) is reported and closes the stream, as before.
2. **Socket drops are no longer reported.** A `channelError` or
`timedOut` status is now reported only when the channel won't rejoin by
itself, for example when the server declines the subscription. Drops and
join timeouts put the channel into its errored state, so it rejoins and
the rows are fetched again. Those are only logged. The `stream()`
dartdoc no longer claims the stream closes when the connection closes.
3. **The snapshot is taken once replication is live.** A successful join
does not yet mean the server streams the changes; the server confirms
that with a `system` event (`extension: postgres_changes`, `status:
ok`). The rows are fetched on that event after every join. If the server
never sends it, a fallback fetch runs after the realtime client's
`timeout`. Changes that arrive during the fetch are buffered and applied
on top of its result. Each fetch has an id, so the result of a
superseded or cancelled fetch is dropped. If the channel cannot join at
all, a `channelError` or `timedOut` before the first snapshot still
triggers a fetch, so the rows are shown without realtime.
4. **A change with `errors` triggers a fetch.** A payload the server
could not send in full (for ex... (continued)

135 of 138 new or added lines in 2 files covered. (97.83%)

11899 of 12836 relevant lines covered (92.7%)

6.19 hits per line