[AIT-286] Fix rules for buffering of incoming object operations during LiveObjects sync

[VeskeR]

Buffered object operations must be cleared on every ATTACHED message,
not at the start of a new OBJECT_SYNC sequence.
If HAS_OBJECTS is set on ATTACHED, the server will deliver a sync
sequence following the attachment, guaranteeing that the objects in
that sequence include at least all operations up to the attach point.
If HAS_OBJECTS is not set, the client performs an implicit sync
sequence by transitioning to SYNCING and immediately clearing local
state. Read more in the LODR-058 [1].

The behaviour for receiving an OBJECT_SYNC without a preceding
ATTACHED is unchanged by this PR and will be addressed separately
in LODR-059 [2].

Resolves AIT-286

[1] https://ably.atlassian.net/wiki/x/NQAEHgE
[2] https://ably.atlassian.net/wiki/x/AYDeHwE

Also this PR clarifies RTO4 structure

[Copilot]

Pull request overview

This PR fixes the BufferedObjectOperations clearing behavior for LiveObjects synchronization by ensuring operations are cleared at the correct time based on when the server caches object state.

Changes:

• Added RTO4d to specify that BufferedObjectOperations must be cleared when ATTACHED is received without the RESUMED flag, since the server caches object state at channel attachment time
• Added RTO5f as an explanatory note describing the expected and edge-case behaviors for server-initiated resyncs
• Deleted RTO5a2b which previously required clearing BufferedObjectOperations when a new sync sequence ID arrived

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[lawrence-forooghian]

Let's have a DR?

In general, the spec usually describes the "what" and not the "why". When it does explain the "why", it usually:

• does it in a concise fashion
• avoids describing Realtime implementation details (e.g. caching), and instead focuses on the contract with clients

I think that we'd benefit from having a short DR explaining the motivation behind this new behaviour.

I think that the two things it should describe are:

• why it would be incorrect to apply the buffered operations after a discontinuity (as opposed to just stating that they're "no longer relevant") — I think this requires more explanation than could be concisely expressed in the spec, and I'll elaborate on this below; we'd then remove the explanation from RTO4d
• the best-effort behaviour currently described in RTO5f, and then remove that spec point

Why it would be an error to apply buffered operations after a discontinuity

Consider the case where the client ends up reconnecting to some different region r_reconnect. Upon attaching in r_reconnect, you're potentially attaching to r_reconnect's message stream at a position where the messages for some given region r are r-regional-order-earlier than the originating-in-r messages that you've buffered.

It's thus possible that there exists some operation m, originating in r, which has not yet been applied to the post-discontinuity sync sequence and which is r-regional order-earlier than the originating-in-r messages that you've buffered. If we were to apply the pre-discontinuity BufferedObjectOperations to the post-discontinuity sync sequence then, upon post-discontinuity receipt of m, we would discard it due to the siteTimeserials check, causing m to — incorrectly — never be applied to our local objects data.

This diagram, showing the events from the point of view of a Realtime client, might explain it better; assume that all of the blue messages are from the same region, and that there exists another earlier message m1 from the same region:

[lawrence-forooghian]

I'd say replaced, not deleted

[VeskeR]

updated to say it was replaced by RTO4d

[VeskeR]

I think that the two things it should describe are:
why it would be incorrect to apply the buffered operations after a discontinuity (as opposed to just stating that they're "no longer relevant") — I think this requires more explanation than could be concisely expressed in the spec, and I'll elaborate on this below; we'd then remove the explanation from RTO4d
the best-effort behaviour currently described in RTO5f, and then remove that spec point

Done both.
DR for this change: https://ably.atlassian.net/wiki/x/NQAEHgE
RTO5f is removed, RTO4d simply tells you to cleared buffered operations array. The DR link is now also in a commit message for easy discovery, as discussed.

Also note: our SDK implementations also had a separate bug where LiveObjects sync handling was only triggered for non-RESUMED ATTACHED messages (fixed in ably-js in ably/ably-js#2150). This is not a spec issue - RTO4 has never conditioned on RESUMED and has always applied to every ATTACHED message. This was purely an implementation bug, likely also present in the Kotlin and Swift plugins.

[lawrence-forooghian]

Also note: our SDK implementations also had a separate bug where LiveObjects sync handling was only triggered for non-RESUMED ATTACHED messages (fixed in ably-js in ably/ably-js#2150). This is not a spec issue - RTO4 has never conditioned on RESUMED and has always applied to every ATTACHED message. This was purely an implementation bug, likely also present in the Kotlin and Swift plugins.

This bug doesn't exist in Swift or Kotlin:

• https://github.com/ably/ably-cocoa/blob/14d2661824652d0c6065dfe4dcf8c2e3781502fc/Source/ARTRealtimeChannel.m#L812-L826
• https://github.com/ably/ably-java/blob/3298bcc27f18b2618c776bf3b8900a5a7351c800/lib/src/main/java/io/ably/lib/realtime/ChannelBase.java#L475-L491

[lawrence-forooghian]

Suggested a few language tweaks in 5b1c1a0 plus addressed #416 (comment)

[lawrence-forooghian]

Would you also please be able to update the part of the commit message that refers to receiving an OBJECT_SYNC without a preceding ATTACHED? I'd suggest either just dropping it (that behaviour isn't touched here) or mentioning what we're planning to do with that behaviour

[VeskeR]

Would you also please be able to update the part of the commit message that refers to receiving an OBJECT_SYNC without a preceding ATTACHED? I'd suggest either just dropping it (that behaviour isn't touched here) or mentioning what we're planning to do with that behaviour

Updated 997584f

Suggested a few language tweaks in 5b1c1a0 plus addressed #416 (comment)

Like the change, thank you. I cherry picked the commit, but moved the RTO4b5 replacement part to the original commit (makes more sense to have all buffering related changes in one commit). So the second commmit now only clarifies RTO4 structure