fix(realtime_client): faster channel rejoin on web

[Vinzent03]

What

Faster disconnect

The previous disconnect first waited for the connection to get stable by waiting for conn.ready. Despite the comment I added on it, I could not find any issues by removing that wait and just close the connection immediately. I tested this manually with the websocket channel package by closing the connection instantaneously and with delays without waiting for conn.ready on web, android and linux. This comment seems to experience the same.
During testing on web, I found that by removing the wait for ready the close is still not instantaneously, but can take several seconds. I think it depends on the exact platform and state of the connection whether this can save time or not.

Timeout for connection close

During testing I experienced a real network issue at home, but no reconnect was scheduled. I lost the exact logs, but when researching other issues I came along this comment: dart-lang/http#1693 (comment) which could be the source of the issue. The disconnect hang indefinitely which is why no connect was scheduled. So I added a timeout to the conn.sink.close. This may cause the disconnect to not wait for a connection that would indeed close after like 10 seconds successfully, but I don't think there is a real issue in handling this via a timeout.

Faster Channel rejoin

In particular, I tested a Flutter web app on mobile by switching from the browser to other apps and back. Only inactive and hidden events are fired on web when switching to another app, which are currently not handled by the app state handler in supabase_flutter. But those events are also called when switching to another tab. But in the case of switching to another tab the websocket connection is kept. When switching to another app that is not the case and the connection is aborted. So the kind of events that are currently handled is correct. There is no way for the app to know by the events whether the connection will stay stable or not. This means we cannot schedule a disconnect as we do for mobile. Due to the errored connection a re-connect is scheduled, which tries to connect for the whole time until the app is reopened.

This causes the channel to hang it a loop of rejoining. Depending on the time of a reconnect it can take a lot of time for the next rejoin to kick in. As seen by the following snippet where it took 10s for the channel to start rejoining after the connection is already established.

14:08:18.073 js_primitives.dart:28 2026-06-25 14:08:18.073: supabase.realtime: FINE: transport: connecting
14:08:18.252 js_primitives.dart:28 2026-06-25 14:08:18.252: supabase.realtime: FINEST: transport: connected to wss://-.supabase.co/realtime/v1/websocket?apikey=-&vsn=2.0.0
14:08:18.252 js_primitives.dart:28 2026-06-25 14:08:18.252: supabase.realtime: FINE: transport: connected
14:08:27.961 js_primitives.dart:28 2026-06-25 14:08:27.958: supabase.auth: FINER: Access token expires in 286 ticks
14:08:28.073 js_primitives.dart:28 Attempting to rejoin channel realtime:public:realtime_test_inserts:0...
14:08:28.081 js_primitives.dart:28 2026-06-25 14:08:28.079: supabase.realtime: FINEST: channel: rejoining realtime:public:realtime_test_inserts:0
14:08:28.102 js_primitives.dart:28 2026-06-25 14:08:28.100: supabase.realtime: FINEST: push: realtime:public:realtime_test_inserts:0 join (27)
14:08:28.235 js_primitives.dart:28 2026-06-25 14:08:28.232: supabase.realtime: FINEST: receive: ok realtime:public:realtime_test_inserts:0 phx_reply (27)
14:08:28.267 js_primitives.dart:28 Subscribed!

The new implementation rejoins all errored channels manually on connection open. This can improve the timings a LOT.

[Vinzent03]

I'm not totally familiar with the new sdk compliance matrix yet. Does the result really mean I have to create a pr to the sdk repo first?

[spydon]

I'm not totally familiar with the new sdk compliance matrix yet. Does the result really mean I have to create a pr to the sdk repo first?

No, you just have to update the sdk-compliance.yaml file with the new public symbols. (Use @internal for things that shouldn't be public and they'll be skipped)

You can see an example in the action:
https://github.com/supabase/supabase-flutter/actions/runs/28981245437/job/86000281687#step:6:1

[spydon]

Lgtm! Only the compliance matrix update missing.

[Vinzent03]

But this is a feature that is not listed in the supabase/sdk repo and every feature listed in the compliance file needs to be present there first, doesn't it? And I don't think @internal is correct since the user should be able to configure this.
Or should it just be added to the existing disconnect feature?

-  realtime.client.disconnect: implemented
+  realtime.client.disconnect:
+    status: implemented
+    symbols:
+      - Constants.defaultConnectionCloseTimeout
+      - RealtimeClient.connectionCloseTimeout
+      - RealtimeClientOptions.connectionCloseTimeou

[spydon]

Or should it just be added to the existing disconnect feature?

Yup, that looks good.