[ECO-5728] Change RTP16a: presence on an ATTACHED channel waits for re-attach when not CONNECTED#490
Open
VeskeR wants to merge 2 commits into
Open
[ECO-5728] Change RTP16a: presence on an ATTACHED channel waits for re-attach when not CONNECTED#490VeskeR wants to merge 2 commits into
VeskeR wants to merge 2 commits into
Conversation
…CONNECTED Replace RTP16a with RTP16d, splitting the handling of presence messages on an ATTACHED channel by connection state: when CONNECTED they are published immediately (RTP16d1, per RTL6c1); when not CONNECTED they are queued at the channel level (RTP16d2) and sent once the channel next reaches ATTACHED (RTP5b), rather than placed on the connection-wide queue (RTL6c2). The connection-wide queue is flushed on connect (RTL3d) before channels have re-attached, which the server rejects for presence, as presence requires a real (non-transient) attachment. RTP16b, RTL11, the RTN7e note, the channel-states-operations table, and the queueMessages IDL annotation are updated to reference the new clauses. Resolves ECO-5728
VeskeR
changed the title
VeskeR
changed the title
VeskeR
added a commit
to ably/ably-js
that referenced
this pull request
Jun 9, 2026
On a transient disconnect that left a channel ATTACHED but the connection not CONNECTED, a presence operation was routed to the connection-wide queue (RTL6c2). On reconnect, RTL3d flushes that queue immediately, before the channel completes its re-attachment, so the server rejected the presence message with "not currently attached" (code 90001). Presence requires a real (non-transient) server-side attachment, unlike messages and objects which only need a transient one. Now, when the channel is ATTACHED but the connection is not CONNECTED, presence is queued at the channel level (RTP16d2) and sent once the channel next reaches ATTACHED (RTP5b), honoring queueMessages. Corresponding spec PR at [1] Resolves ECO-5728 [1] ably/specification#490
Addresses review feedback on PR #2241 for ECO-5728. The earlier RTP16d clause modelled presence queuing at the channel level based on the connection state. The behaviour is instead specified at the connection level, matching ably-java. The new RTL3d2 requires that, when the connection becomes CONNECTED, presence messages queued per RTL6c2 for a channel that RTL3d is (re-)attaching are not sent immediately but queued at the channel level per RTP16b, to be sent once the channel re-attaches (RTP5b). RTL3d's parenthetical now carves these presence messages out of its immediate-flush instruction.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces RTP16a (which routed presence on an ATTACHED channel to the
connection-wide queue) with RTP16d, splitting the handling by connection state:
channel next reaches ATTACHED (RTP5b).
This stops presence being flushed on connect (RTL3d) before a channel has
re-attached, which the server rejects. RTP16b, RTL11, the RTN7e note, the
channel-states-operations table, and the queueMessages IDL annotation now
reference the new clauses.
Implemented in ably-js: ably/ably-js#2241.
Resolves ECO-5728