From 0f75131a8920d5957cb467133e5fbc5ee818dc73 Mon Sep 17 00:00:00 2001 From: Simon Woolf Date: Tue, 24 Mar 2026 10:41:12 -0400 Subject: [PATCH] ADD RTL3d1 requiring channel state transitions to happen before the connected event This ensures that when a connection listener observes the `CONNECTED` state, channels that were previously `ATTACHED` are already in the `ATTACHING` state. Without this ordering guarantee, a connection listener calling `attach()` on a channel per `RTL4a` would see the channel as `ATTACHED` and receive an immediate success callback without a server round-trip, potentially leading to operations (such as presence enter) being performed on a channel that in reality is not attached --- specifications/features.md | 1 + 1 file changed, 1 insertion(+) diff --git a/specifications/features.md b/specifications/features.md index 6df4e2d5..3c48b487 100644 --- a/specifications/features.md +++ b/specifications/features.md @@ -686,6 +686,7 @@ The threading and/or asynchronous model for each realtime library will vary by l - `(RTL3b)` If the connection state enters the `CLOSED` state, then an `ATTACHING` or `ATTACHED` channel state will transition to `DETACHED` - `(RTL3c)` If the connection state enters the `SUSPENDED` state, then an `ATTACHING` or `ATTACHED` channel state will transition to `SUSPENDED` - `(RTL3d)` If the connection state enters the `CONNECTED` state, any channels in the `ATTACHING`, `ATTACHED`, or `SUSPENDED` states should be transitioned to `ATTACHING` (other than ones already in that state), and initiate an `RTL4c` attach sequence. (If the attach operation times out and the channel was previously `SUSPENDED`, it should return to the `SUSPENDED` state, see [RTL4f](#RTL4f)). The connection should also process any messages that had been queued per `RTL6c2` (it should do this immediately, without waiting for the attach operations to finish). + - `(RTL3d1)` The `RTL3d` channel state transitions must be applied before the `CONNECTED` connection state change is emitted to external listeners. - `(RTL11)` If a channel enters the `DETACHED`, `SUSPENDED` or `FAILED` state, then all presence actions that are still queued for send on that channel per [RTP16b](#RTP16b) should be deleted from the queue, and any callback passed to the corresponding presence method invocation should be called with an `ErrorInfo` indicating the failure - `(RTL11a)` For clarity, any messages awaiting an `ACK` or `NACK` are unaffected by channel state changes i.e. a channel that becomes detached following an explicit request to detach may still receive an `ACK` or `NACK` for messages published on that channel later - `(RTL4)` `RealtimeChannel#attach` function: