From 14adb3dda8153b80e1b0225849614cd77096b10d Mon Sep 17 00:00:00 2001 From: Andrew Bulat Date: Fri, 19 Jun 2026 11:34:21 +0100 Subject: [PATCH] Defer queued presence to channel re-attach on connect (RTL3d2) When the connection reaches CONNECTED, RTL3d re-attaches the channels that were attaching, attached, or suspended, and otherwise flushes the messages queued per RTL6c2 immediately. Presence messages are handled differently: a channel that is being re-attached is not yet attached on the connection, so sending its queued presence immediately would be rejected. RTL3d2 requires those presence messages to instead be queued at the channel level (RTP16b) and sent once the channel re-attaches (RTP5b). RTL3d's immediate-flush instruction now carves them out. Resolves ECO-5728 --- specifications/features.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specifications/features.md b/specifications/features.md index c96fffb2a..b09740d9b 100644 --- a/specifications/features.md +++ b/specifications/features.md @@ -687,8 +687,9 @@ The threading and/or asynchronous model for each realtime library will vary by l - `(RTL3a)` If the connection state enters the `FAILED` state, then an `ATTACHING` or `ATTACHED` channel state will transition to `FAILED` and set the `RealtimeChannel#errorReason` - `(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). + - `(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, other than the presence messages described in [`RTL3d2`](#RTL3d2)). - `(RTL3d1)` The `RTL3d` channel state transitions must be applied before the `CONNECTED` connection state change is emitted to external listeners. + - `(RTL3d2)` When processing the messages that had been queued per [`RTL6c2`](#RTL6c2), any presence messages for a channel that `RTL3d` is (re-)attaching must not be sent immediately; they should instead be queued at the channel level (per [`RTP16b`](#RTP16b)). - `(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: