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

[VeskeR]

BufferedObjectOperations should only be cleared when ATTACHED with RESUMED flag not set is received or on sync completion, not when a new sync sequence ID arrives. This is because the server caches object state at channel attachment time, not at the start of a sync sequence.

Resolves AIT-286

See ably-js implementation ably/ably-js#2150

[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.

[Copilot]

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.

[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