[kriszyp]

⊙ Problem

On audit: false tables, a patch older than or tied with the stored record skipped the checks the audited path makes. A patch older than a delete or a publish brought the record back, indexed. A re-delivered patch applied its add again. On RocksDB, a put or patch after a publish to the same key in one transaction was dropped.

🤔 Is the requirement right as specified?

Mostly. The task also asked LMDB to keep the head's version after a merge (#3388). That version is also LMDB's optimistic-lock token, so keeping it loses concurrent writes.

💡 Solution

For an older or tied write on an audit: false table:

• A write is skipped if it ties the head, the head has no record (delete, publish), or the head already lists it.
• A merge that applies a commutative op records its identity, so a re-delivery is skipped.
• A tie left by a relocate or publish in the same transaction, before or after the write, is ordered against the committed head on RocksDB: newer applies, older merges only its ops, equal is a re-delivery.

Fixes #3385. Refs #3388.

⚖️ Alternatives

Rejected alternatives

• Keep the head's version on LMDB (Math.max): LMDBTransaction.commit checks ifVersion(key, entry.version), so keeping the version lets a write staged before the merge commit over it.
• Return null from remainingAgainstRecord for a missing record: the delete rule is Table policy (already in belowAuditFloor), and the helper cannot detect duplicates.

🤔 Should a same-origin tie with a different log key count as a duplicate?

Yes. An audit: false head stores no log key, so a re-delivery and a distinct same-version write look identical.

🤔 Should an older patch over a publish-only head be dropped?

Here it is: without a log, a publish-only head looks like delete-then-publish. The cost: a patch arriving first creates the record.

🤔 Should receipts get their own record field?

They reuse receivedIdentityRefs, avoiding a format change; old receipts can age out of the bounded list.

🤔 Should the out-of-order arm avoid its extra walk and allocation?

No: the walk is bounded by one transaction's same-key writes, and the allocation is on the rare merge path.

🔧 Changes

• resources/Table.ts, _writeUpdate's out-of-order block: the committed-head ordering for a tie a same-transaction publish or relocate made, the in-order branch, then ⚠️ Look hardest: the tie, missing-record and listed-identity checks, then receipts. Receipts are keyed by receivedLogKey and recorded only when the merge folds in a commutative op.
• resources/DESIGN.md: receipts on unaudited records and their best-effort limits, why LMDB still rewinds, the skip inventory, the program-order rule.
• unitTests/resources/noAuditOutOfOrderPatch.test.js: 23 new cases on both engines (first new case).

✅ Verification

• noAuditOutOfOrderPatch.test.js: 29/29 on RocksDB, including an older patch after a delete, tie re-delivery, out-of-order re-delivery and a write staged before a merge. On LMDB 17 pass, 12 skipped. npm run test:unit:resources:core: 4533 passing on RocksDB.
• PR QA: Does a replicated audit:false transaction that patches and publishes one key, in either order, converge on both nodes and apply its increment once on re-delivery? — queued @ f8428ef, qa-pr-harper-3506-f8428ef

New test cases

• Older patch after a delete: no record, no index entry, blob reclaimed.
• Older patch after a publish to an absent key: no record, no index entry.
• Newer patch after a delete still recreates the record (control).
• Delete then patch in one transaction still applies (control).
• Publish then patch, publish then put, publish to an absent key then patch, all in one transaction, still apply.
• A replicated patch and publish, in either order, apply over an older head, merge only their ops under a newer head, and apply once on re-delivery (RocksDB).
• Tie re-delivery of an add applies once.
• Out-of-order re-delivery applies once, including two merges each re-delivered (RocksDB).
• Same-timestamp patches from two origins both merge (RocksDB).
• A re-delivered two-patch transaction applies each patch once.
• The merge keeps the head version, so older patches and deletes still lose (RocksDB).
• Receipts are stored per origin and log key, and a plain-key merge adds none of its own (RocksDB).
• Applied writes sharing a record version but not a log key both merge (RocksDB).
• A write staged before an out-of-order merge commits does not overwrite it (both engines; guards against the LMDB Math.max change).

🤖 Generated with Claude Code

_{🤖 Generated by Anthropic Claude (Opus 5.5); posted via @kriszyp.}

Release target: v5.4 — extends #3411's audit:false branch, which is on v5.4 only

Related PRs: #3469 overlaps (adjacent full-update branch; expect a textual conflict), #3499 overlaps (merged; same-transaction publish/relocate tie, audited path; rebased onto it), #3411 overlaps (merged; this extends its audit:false branch), #3476 overlaps (merged; committed-head duplicate skip, audited path), #3510 overlaps (merged; minted local log keys and the received-identity list the receipts now use; rebased onto it), #3423 overlaps (merged; replication confirmation note in DESIGN.md; rebased onto it), #3576 overlaps (merged; distinct origins never tie, so the tie skip is same-origin only; rebased onto it), #3529 overlaps (merged; added followsAppliedWrite, reused here; rebased onto it), 20 others independent
Complexity: complicated
Framing-Verdict: chosen-approach-sound

Deferred findings

• e88fb92adebeea8b minor data-integrity — resources/Table.ts — chained same-txn out-of-order plain-field patch dropped against prior staged record — NOT FILED
• 367176ab4120fb41 minor data-integrity — resources/Table.ts — in-order write on audit:false drops receivedIdentityRefs, so re-delivery of an earlier commutative merge double-applies — NOT FILED
• e06173778072dd87 minor data-integrity — unitTests/resources/noAuditOutOfOrderPatch.test.js — LMDB drops patch before same-txn publish; new tests skip LMDB — NOT FILED
• 9cef1ac0381dadf8 minor data-integrity — resources/Table.ts — an older replicated publish rewinds the head version below a newer committed write — NOT FILED
• 3001c44f2fdb2aa6 minor data-integrity — resources/Table.ts — re-delivered [publish K, patch K] re-applies the patch's commutative ops on LMDB — NOT FILED
• de38970ada68f5aa minor data-integrity — unitTests/resources/noAuditOutOfOrderPatch.test.js — dedup and publish arms skipped on LMDB — NOT FILED
• c2574982c64bc159 minor data-integrity — resources/Table.ts — LMDB merge stores the older version; a later older-than-head write compares in-order — NOT FILED

Origin — the dispatch brief this PR was written from

Fixes #3385 and #3388 plus two untracked siblings, all in the audit:false patch branch of Table._writeUpdate (resources/Table.ts ~5535-5547), which after #3411 is remainingAgainstRecord(...), skip if nothing remains, set write.superseded, with no tie, null-head or duplicate guard (the audited and belowAuditFloor branches have all three, e.g. ~5518-5528). remainingAgainstRecord returns the whole update for a null record and always keeps op keys, so: (D1, #3385) an old patch past a delete tombstone recreates an id: undefined record in primary and secondary indexes and leaks blobs (also via Table.publish null entries on trackDeletes:false tables); (D2) an exact-timestamp re-delivery double-applies add; (D3) an out-of-order duplicate re-applies because existingEntry.additionalAuditRefs is never consulted, and writeCommit (~5714) wipes the list; (D4, #3388, LMDB) writeCommit uses Math.max(txnTime, existing version) only on RocksDB (~5694), so LMDB rewinds the head version. Skip the write (write.skipped = true; return writeCommit(false)) when the txn ties the existing version, the existing record is null, or additionalAuditRefs already holds this (txnTime, nodeId); when a partial merge applies, carry additionalAuditRefs forward and add this write's ref as the belowAuditFloor branch does; use the Math.max version rule on LMDB too. Draft PR #3469 edits the adjacent audited block; expect a textual conflict.

Acceptance

Dual-engine tests on an audit:false table: old patch after delete does not recreate the row (no index entry, no leaked blob); tie re-delivery of an add applies once; out-of-order duplicate add applies once; LMDB head version never decreases. Controls: in-order and genuine out-of-order patches still merge. Shown failing on origin/main.

_{Dispatch: task harper-noaudit-patch-tie-null-dup-guards · queued by finding-triage/wave-39 · ran by claude/opus/xhigh · worker kzyp-xps-1}

Late Grok findings

11 surviving (highest major) — Grok reviewed 9759ff4

• major — resources/Table.ts:5847 — Source-applied audit: false transaction [patch K count+=4, message K] (seed count 10 at v50, frame at v100): the message saves eagerly and restamps K to v100; the deferred patch reloads that entry, ties with it, and the tie exception checks only earlier writes (priorWritesSkipped), not later o
• minor — resources/Table.ts:5862 — existingRecord == null treats a publish-only head like a delete tombstone. In-order delivery (patch T50, then publish T100) keeps the record; out-of-order delivery leaves no record; the audited walk creates it. Peers end up with different data, and the test at `unitTests/resources/noAuditOutOfOrde
• minor — resources/Table.ts:5861 — precedesExisting === 0 skips on record-version equality alone. A distinct same-origin write at version 100 / log key 110 against a head at version 100 / log key 100 loses its count += 4
• minor — resources/Table.ts:5995 — In-order writes on audit: false carry no receipts forward. So: T50 out-of-order add (receipt stored), then T150 in-order patch, then re-delivery of T50 applies the add a second time (count 15 → 18)
• minor — resources/Table.ts:10319 — priorWritesSkipped walks the whole predecessor chain, and every skipped same-key write calls it again (resources/Table.ts:5847, resources/Table.ts:5864). Re-delivering N same-key writes costs N(N−1)/2 inspections
• minor — resources/Table.ts:5880 — commutativeOpsOf builds a full projection whose only use is a truthiness test, and the receipts are sliced before anyone knows a push will happen. Both are per-patch allocations on the out-of-order audit: false branch
• minor — resources/Table.ts:8372 — A re-delivered [publish K, patch K] transaction applies the patch's commutative ops again (deferred: noaudit-publish-then-patch-redelivery-double-apply)
• nit — resources/Table.ts:5880 — On LMDB, a chained same-transaction patch rebuilds receipts from the pre-transaction entry and drops the receipt the earlier patch staged. No double-apply follows today because the LMDB merge stores the record at txnTime
• nit — resources/Table.ts:5847 — The empty else if branch only works because incrementalUpdateToApply stays unset; an explicit assignment would survive later edits
• nit — resources/DESIGN.md:146 — The receipt note does not say what happens to unaudited receipts once auditing is turned on (the audited check reads them only under identityIsNotKey), or mention the encoder-budget limit
• nit — unitTests/resources/noAuditOutOfOrderPatch.test.js:16 — Comment nits, all in one: "as on main" at test line 16 is addressed to the reviewer, and the null-guard narration at resources/Table.ts:5858-5859 restates the condition below it. The applyFrom comment at test line 132 is borderline

Not standing: 2 separate-issue. Grok ran 15m (15m from launch to report); the fold adjudication (cursor-grok@9759ff40a9c6-9aee4a61, claude) took 2m.

Late Grok findings

1 surviving (highest minor) — Grok reviewed e58cfa9

• minor — resources/Table.ts:5892 — on an audit: false table, the next in-order write throws away the receipt from a commutative out-of-order merge. A re-delivery of that merge then applies its ops a second time (count 10 → 13 → 16)

Not standing: 1 separate-issue. Grok ran 12m (12m from launch to report); the fold adjudication (cursor-grok@e58cfa93ee41-9901dfce, claude) took 1m.

_{Review-Coverage: authored=claude; ran=cursor-composer,gemini,codex,cursor-grok; late=cursor-grok:adjudicated; adjudicated=domain; blocked=claude(fallback)(out-of-budget); declined=muse; rounds=20; full=7 @ a6212d0}

_{Review-Attention: study ~15m (critical: Table.ts; decisions: noaudit-tie-is-duplicate, null-head-skip-includes-publish, receipts-on-record-best-effort, lmdb-arms-deferred) @ a6212d0}

[gemini-code-assist]

Code Review

This pull request updates the out-of-order patch handling on tables with auditing disabled (audit: false). It ensures that older patches do not resurrect deleted records or materialize records over newer publishes, correctly handles program-order ties when earlier writes restamped the head without staging, and tracks merged write identities in additionalAuditRefs to recognize re-delivered patches. Corresponding documentation in DESIGN.md and comprehensive unit tests in noAuditOutOfOrderPatch.test.js have been added. I have no feedback to provide as there are no review comments to assess.