fix(auditlog): advance the served-rowid mark under the write lock so a purge clamp is never overwritten stale-high (review 2026-10-21 follow-up L1)

2026-10-22 09:44:38 -04:00
parent 1f87942ce3
commit 530a096111
3 changed files with 77 additions and 29 deletions
@@ -511,7 +511,18 @@ resets it — before that, a healthy site whose pull serves nothing could leave
 `PushAbandoned`/`Rejected` rows owed (and counted on the backlog) indefinitely. It stays
 conservative in the safe direction (retirement can be delayed, never a row lost). The gRPC handler's ordering
 (retire, *then* read) is what keeps the bound from ever vouching for the batch it is
-about to serve.
+about to serve. The mark is advanced under the writer's write lock — the same lock
+the purge's rowid clamp runs under — so a clamp can never be overwritten with a stale-high
+value by a concurrent pull (review 2026-10-21 follow-up L1).
+
+**The bound protects a late-stamped row for one pull cycle, not forever.** A row inserted
+after a batch was served but stamped *below* central's cursor has a rowid above the mark,
+so the next cursor cannot retire it — but the pull never serves it either (the keyset read
+is already past its timestamp), and as soon as a later pull serves any newer row the mark
+rises above it and the following cursor retires it. Its delivery therefore relies on the
+telemetry **push**, which drains every `Pending` row oldest-first regardless of the pull
+cursor and will normally have acked it (`Forwarded`, untouched by the cursor) within that
+cycle; the served-rowid bound only buys the push that window.

 **Liveness note (accepted, documented).** A row that was served but never covered by a
 later cursor — central reconciliation stopped for good — stays owed (`Pending` /