Skip to content

[AIT-286] Fix BufferedObjectOperations clearing rules for LiveObjects sync #416

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

Open
VeskeR wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[AIT-286] Fix BufferedObjectOperations clearing rules for LiveObjects sync #416

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
4 changes: 3 additions & 1 deletion textile/objects-features.textile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -104,6 +104,7 @@ h3(#realtime-objects). RealtimeObjects
*** @(RTO3b1)@ Upon initialization of the @ObjectsPool@, create a new @LiveMap@ (per "RTLM4":#RTLM4) with @objectId@ set to @root@ and add it to the @ObjectsPool@
* @(RTO4)@ When a channel @ATTACHED@ @ProtocolMessage@ is received, the @ProtocolMessage@ may contain a @HAS_OBJECTS@ bit flag indicating that it will perform an objects sync, see "TR3":../features#TR3 . Note that this does not imply that objects are definitely present on the channel, only that there may be; the @OBJECT_SYNC@ message may be empty
** @(RTO4c)@ Upon receipt of an @ATTACHED@ @ProtocolMessage@, the "RTO17":#RTO17 sync state must transition to @SYNCING@ if not already @SYNCING@. This must occur before performing any "RTO4b":#RTO4b actions.
** @(RTO4d)@ If the @RESUMED@ flag (see "TR3":../features#TR3) is not set, the @BufferedObjectOperations@ list must be cleared without applying any buffered operations. This is because the realtime server caches the object state at the moment of channel attachment, so any previously buffered operations are no longer relevant to the state that will be received during the sync sequence
** @(RTO4a)@ If the @HAS_OBJECTS@ flag is 1, the server will shortly perform an @OBJECT_SYNC@ sequence as described in "RTO5":#RTO5
** @(RTO4b)@ If the @HAS_OBJECTS@ flag is 0 or there is no @flags@ field, the sync sequence must be considered complete immediately, and the client library must perform the following actions in order:
*** @(RTO4b1)@ All objects except the one with id @root@ must be removed from the internal @ObjectsPool@
Expand All @@ -115,11 +116,12 @@ h3(#realtime-objects). RealtimeObjects
* @(RTO5)@ The realtime system reserves the right to initiate an objects sync of the objects on a channel at any point once a channel is attached. A server initiated objects sync provides Ably with a means to send a complete list of objects present on the channel at any point
** @(RTO5d)@ If an @OBJECT_SYNC@ @ProtocolMessage@ is received and "@ObjectMessage.object@":../features#TR4r is null or omitted, the client library should skip processing that @ProtocolMessage@
** @(RTO5e)@ When an @OBJECT_SYNC@ @ProtocolMessage@ is received with a @channel@ attribute matching the channel name, the "RTO17":#RTO17 sync state must transition to @SYNCING@ if not already @SYNCING@. This must occur before performing any "RTO5c":#RTO5c sync completion actions.
** @(RTO5f)@ Note: The expected behavior for a server-initiated resync is that the @OBJECT_SYNC@ message will be preceded by an @ATTACHED@ message with @RESUMED@ flag not set, which clears buffered operations per "RTO4d":#RTO4d. However, if an @OBJECT_SYNC@ arrives after a previously completed sync without a preceding @ATTACHED@ message, the client library handles this on a best-effort basis: by transitioning to @SYNCING@ (per "RTO5e":#RTO5e) and starting to buffer @OBJECT@ messages (per "RTO8a":#RTO8a) from that point onwards (since the client does not know at which point the state being received was cached by the server). This best-effort handling is achieved implicitly through the existing spec points and requires no additional implementation
** @(RTO5a)@ When an @OBJECT_SYNC@ @ProtocolMessage@ is received with a @channel@ attribute matching the channel name, the client library must parse the @channelSerial@ attribute:
*** @(RTO5a1)@ The @channelSerial@ is used as the sync cursor and is a two-part identifier: @<sequence id>:<cursor value>@
*** @(RTO5a2)@ If a new sequence id is sent from Ably, the client library must treat it as the start of a new objects sync sequence, and any previous in-flight sync must be discarded:
**** @(RTO5a2a)@ The @SyncObjectsPool@ list must be cleared
**** @(RTO5a2b)@ The @BufferedObjectOperations@ list must be cleared
**** @(RTO5a2b)@ This clause has been deleted
Copy link

Copilot AI Jan 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The deleted clause statement should end with a period for consistency with other deleted clauses in the specification (see RSN4c, TS3, etc. in features.textile).

Suggested change
**** @(RTO5a2b)@ This clause has been deleted
**** @(RTO5a2b)@ This clause has been deleted.

Copilot uses AI. Check for mistakes.
*** @(RTO5a3)@ If the sequence id matches the previously received sequence id, the client library should continue the sync process
*** @(RTO5a4)@ The objects sync sequence for that sequence identifier is considered complete once the cursor is empty; that is when the @channelSerial@ looks like @<sequence id>:@
*** @(RTO5a5)@ An @OBJECT_SYNC@ may also be sent with no @channelSerial@ attribute. In this case, the sync data is entirely contained within the @ProtocolMessage@
Expand Down
Loading