What?

When an RTC polling request fails, convert queued updates into a compaction update instead of replaying them.

Why?

In at least one instance, we have observed a cascading failure that results in thousands of duplicate updates, eventually resulting in OOM errors. This appears to happen when the server request fails after it successfully writes the provided updates—either because of an unknown code failure or because of a timeout or other transport issue.

When this happens, the client detects the failure and restores the updates to the queue. The exact same updates are then sent on the following poll request.

If this pattern repeats, updates are continuously duplicated leading to unbounded growth of sync data and eventual OOM errors.

How?

Instead of blindly replaying updates on failure, we must accept the possibility that the updates were successful.

This PR replaces the queue restore() strategy with compaction: instead of re-sending the updates, the client encodes its full document state as a single compaction update and clears the queue. This is safe because:

• If the server stored the original updates before the error, the compaction supersedes them.
• If it didn’t, the compaction contains the same state.
• Sending the same compaction multiple times is idempotent (Yjs CRDT merge).

When endCursor is still 0 (no successful poll yet), we fall back to restore() since the queue only contains the initial sync_step1 update and there’s no meaningful document state to compact. Additionally, compaction updates require an endCursor so that they target existing updates.

In theory, it's still possible for this issue to manifest on the very first poll request that contains updates, but the risk should be dramatically reduced.