Skip to content

ADD RTL3d1 requiring channel state transitions to happen before the connected event #442

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
SimonWoolf merged 1 commit into from
Mar 24, 2026
Merged

ADD RTL3d1 requiring channel state transitions to happen before the connected event #442

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions specifications/features.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down
Loading