A snapshot subscription can drop a write made during its initial scan #2933

When a collection subscription starts with a current-state snapshot (Table.subscribe without omitCurrent: WebSocket and SSE connect, and an MQTT subscribe that wants retained values), live events that arrive during the scan are buffered in pendingRealTimeQueue. After the scan, the buffer is filtered against cursorMaxTime, the newest record time the scan saw:

pendingRealTimeQueue = pendingRealTimeQueue.filter((event) => (event.localTime ?? event.version) > cursorMaxTime);

subscription.startTime is then set to cursorMaxTime, so the broadcaster also skips any record at or below it that it has not yet dispatched.

The filter exists to drop pre-subscribe events whose effect the scan already delivered. But cursorMaxTime is a maximum over every scanned row, so it also drops events the scan never covered:

1. The scan visits record R and sends its value as of time 90.
2. R is updated at 110. The event is buffered.
3. Record S, later in key order, is updated at 120, and the scan then visits it. cursorMaxTime becomes 120.
4. The filter drops R's event (110 ≤ 120). The subscriber keeps R as of 90 until R is written again.

The same happens to a message published to a record during the scan: messages do not change the stored value, so the scan cannot have delivered one.

This is silent. The subscriber sees no error, and a rarely-written record can stay stale indefinitely. The trigger is ordinary: any write to an already-scanned record while later rows have newer writes, which is common for a large table under write load.

Suggested fix. Drop a buffered event only when the scan delivered the same record at a version at or above the event's. Or drop nothing: the comment above the scan already accepts duplicate delivery ("Retained-message semantics: subscriber may legitimately receive a record twice ... We don't dedupe"). Either way, subscription.startTime should not advance to cursorMaxTime over records the scan did not cover.

Found while designing harper#2448's MQTT change, whose opt-in progress tracking keeps every buffered event rather than rely on this filter.