[kriszyp]

⊙ Problem

Since #3476, a replicated transaction that writes a record and also publishes to or relocates it can lose the write: the receiver keeps the old value and logs nothing. A publish or relocate saves as soon as it is added, updating the record before the put's commit checks for a duplicate, so the put matches it and is skipped.

🤔 Why does this reach v5.3 through #3478 rather than its own cherry-pick?

#3478 carries #3476 to v5.3 and would ship the same loss, so this fix is folded into it once merged; v5.3 never gets #3476 alone. This PR is therefore unmilestoned, which keeps the workflow from picking it separately.

💡 Solution

• The duplicate checks read the committed record when another write to that key has already saved in the transaction; otherwise the transaction's own view.
• A re-delivered relocate that matches the committed record is skipped instead of restamping it.

⚖️ Alternatives

• Always read the committed record — simplest, but every re-delivered duplicate pays a read and a decode.
• Check only the earlier writes to the key — what Skip relayed duplicates of a record's committed head without reading the transaction log #3476 shipped; it misses a publish or relocate added after the put.

🤔 Is the committed read cheap enough?

I think so. It runs only when another write to the key has saved unskipped, which in practice means a publish or relocate in the same transaction. A source-applied [message, put] measured about 3 µs above main (49.8–77.3 against 47.7–75.4 µs, 1 KB records), and main there skips the put. A single write, or a re-delivered put and patch, reads nothing.

🔧 Changes

• resources/Table.ts: identityBase picks the record both duplicate checks read; _writeRelocate skips at the committed head; priorWritesSkipped is removed.
• resources/DatabaseTransaction.ts: linkWrite keeps the key id on the write, so the check does not re-encode the key.
• resources/DESIGN.md: the head-tie note says where identity comes from.
• unitTests/resources/relayedHeadTieDuplicate.test.js: ordering, re-delivery, read-count, relocate and competing-delivery cases.

✅ Verification

• Fail on main: a put before a same-key message or relocate keeps the old value; a put with a message whose log key differs from its version keeps the old value; a re-delivered put and message never created the record. All pass with the fix.
• Without the relocate skip, re-delivering a non-resident relocate and its put replaces the full record with a stub.
• A competing delivery that commits while a publish is staged forces a retry, and the value converges.
• test:unit:resources: 4637 passing. The [put, delete] case in replicatedDeleteRedelivery.test.js fails alone on main too; an HNSW allow-set test failed once in the full run and passes alone with and without this change.

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

Release target: main — reaches v5.3 folded into #3478 (the #3476 backport), not as a separate cherry-pick
Related PRs: #3476 overlaps (fixes its regression), #3478 overlaps (v5.3 backport of #3476 that must carry this), #3453 overlaps (same design-note bullet and dedup path), #3375 overlaps (changes relocate, which now skips at the committed head), #3401 overlaps (same commit handler), 7 others independent
Complexity: complicated

Deferred findings

• f8d14ea99889b0dd minor data-integrity — resources/Table.ts — same-version restamp committed in a separate receiver txn masks a later put — NOT FILED
• 0f8b86123de7ea9d minor data-integrity — resources/Table.ts — retry re-saves an eager relocate after the deferred put, so it stubs over the staged put — NOT FILED
• 87aefe2d0b974466 nit maintainability — resources/DatabaseTransaction.ts — priorWrite/chainsStagedState field comments restate linkWrite — NOT FILED

Late Grok findings

3 surviving (highest major) — Grok reviewed c916aaa, ruled against 4a47e38

• major — resources/Table.ts:9584 — On a replicated redelivery, a key written more than once in one transaction pays an uncached synchronous primary read and record decode for every write that ties the stored version. The read also runs before the additionalAuditRefs rejection at resources/Table.ts:9594, so writes that check then
• minor — resources/Table.ts:9584 — If a separate receiver transaction commits a same-version restamp, a later write to that key reads it as the head and its put is skipped. This was deferred earlier on this branch and is unchanged at this HEAD.
• nit — resources/DESIGN.md:150 — The note still says identity is "read from the committed record, outside the transaction". That is no longer always true: a key's only write in the transaction is now decided from its commit base, and only keys written more than once get the separate committed read (resources/Table.ts:9584-9588).

Not standing: 1 merged. Grok ran 26m (26m from launch to report); the fold adjudication (cursor-grok@c916aaa5cee3-05ba8ae3, claude) took 1m.

Late Grok findings

1 surviving (highest major) — Grok reviewed 2be36df

• major — resources/Table.ts:9639 — When a source transaction with a put and a same-key relocate is delivered a second time, and the relocate's residency list excludes this host, the receiver ends up with the relocate stub while peers that got the transaction once keep the full record. On the second delivery the relocate is not recogn

Not standing: none. Grok ran 14m (14m from launch to report); the fold adjudication (cursor-grok@2be36dfd8308-3ea09e43, claude) took 2m.

_{Review-Coverage: authored=claude; ran=cursor-composer,codex,gemini,cursor-grok; adjudicated=domain; declined=muse; rounds=8; full=4 @ 5f8bfe9}

_{Review-Attention: study ~20m (critical: DatabaseTransaction.ts, Table.ts; decisions: keyid-cached-on-every-write, committed-read-vs-stashed-base, relocate-implicit-head-only, release-target-vs-evidence) @ 5f8bfe9}

[github-actions]

Release cherry-pick v5.3: cancelled

Cherry-pick branch cherry-pick/v5.3/pr-3499 was deleted — this PR no longer targets v5.3 (milestone is now <none>).

[gemini-code-assist]

Code Review

This pull request updates the transaction replication and duplicate-detection logic to use the committed identity before audit I/O. Specifically, it introduces identityBase to determine the commit base, checking if another write to the same key in the transaction has saved without being skipped, and falls back to reading from the committed record outside the transaction if needed. It also adds helper functions committedEntry and isHeadIdentity to refine head-identity checks and prevent re-delivered relocates from restamping the committed head. Corresponding unit tests have been added to cover these scenarios, including competing deliveries and re-delivered relocates. There are no review comments, so I have no feedback to provide.