[github-actions]

⊙ Problem

This brings two main fixes to v5.3:

• #3476: skip relayed duplicates of a record's committed head without reading the transaction log (#3467).
• #3499: its follow-up. Skip relayed duplicates of a record's committed head without reading the transaction log #3476 alone dropped a replicated put when the same source transaction also published or relocated that key after the put.

🤔 Should #3499 ride along?

Yes. Without it, this cherry-pick would ship #3476's put-drop to v5.3. The drop reproduced on this branch before #3499 was added.

💡 Solution

Both commits are ported with v5.3's single log key. v5.3 has no origin-closed floor, so main's receivedLogKey === txnTime && appendedLogKey === receivedLogKey becomes txnLogKey === txnTime. Main-only code next to the changes stays out: #3183's skip marking on an older relocate, and the priorStaged and receivedIdentityRefIsReceipt parts of the ref check.

🤔 Is a base-copied row's head at V a whole transaction?

I assume yes, as main does. On first delivery, a put and a patch at V over a copied row at V are both skipped. That is wrong only if a copy could hold part of a transaction. A copy is one snapshot.

🔧 Changes

• resources/Table.ts identityBase: decides head identity from the committed record when another same-key write already saved without being skipped. It replaces Skip relayed duplicates of a record's committed head without reading the transaction log #3476's priorWritesSkipped.
• The _writeUpdate head-tie skip now runs on first delivery too, gated by txnLogKey === txnTime. Look hardest here. The ref check reads its refs from the same record.
• _writeRelocate skips a source-applied relocate that ties with the committed head.
• resources/DatabaseTransaction.ts linkWrite caches the write's keyId for that lookup.
• resources/DESIGN.md: keeps v5.3's additionalAuditRefs text and takes main's head-tie bullet unchanged.
• unitTests/resources/relayedHeadTieDuplicate.test.js: byte-identical to main. Its 13 cases include a put before and after a same-key message or relocate.

✅ Verification

• The ported lines match main's squashes, except for the v5.3 log-key mapping above.
• A reversed-order probe ([put, message], [put, relocate]) gives old with Skip relayed duplicates of a record's committed head without reading the transaction log #3476 alone (the put was dropped) and new on v5.3 and on this head.
• relayedHeadTieDuplicate + replicatedRetryDuplicate: 26 passing. test:unit:resources: 4151 passing, 0 failing.
• Dispatched node-24 integration-tests.yml and unit-test.yml on c8f95d0.

Refs #3467

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

Release target: v5.3 — cherry-pick of #3476 with its follow-up #3499

Related PRs: #3476 overlaps (source), #3499 overlaps (source), #3453 overlaps, #3506 overlaps, #3469 overlaps, #3423 overlaps, #3375 overlaps, 14 others independent
Complexity: complicated

_{Review-Coverage: authored=claude; ran=gemini,cursor-composer,codex,cursor-grok; adjudicated=domain; declined=muse; rounds=2; full=1 @ c8f95d0}

_{Review-Attention: study ~20m (critical: DatabaseTransaction.ts, Table.ts; decisions: head-tie-skip-on-first-delivery, committed-read-over-staging-eager-writes) @ c8f95d0}

[kriszyp]

Conflicts resolved at 85cc095. v5.3 has a single log key (no receivedLogKey/appendedLogKey split from #3085), so the head-tie guard keeps its txnLogKey === txnTime condition and gains priorWritesSkipped(write); DESIGN.md keeps v5.3's refs paragraph plus the #3467 bullet. The changed lines are identical to #3476's. On v5.3 with its own dependencies (rocksdb-js 2.11.0), relayedHeadTieDuplicate.test.js passes all 5 cases; the related suites have one failure (the [put, delete] re-delivery case in replicatedDeleteRedelivery.test.js), which also fails on unmodified v5.3.

Note: the cherry-pick workflow recreates this branch whenever #3476's branch is pushed or merged, which drops this resolution; it then has to be re-applied.

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

[kriszyp]

Held — do not merge. #3476 drops a put when a later write to the same key in the same source transaction is a publish/message or relocate: [put r, message r] at one version keeps the old value. Those writes save eagerly when added, so they restamp the record before the put's commit decides its head tie. This backport would ship the same defect to v5.3. The fix is going to main first, deciding the tie against the committed entry instead of the transaction's staged base; its commit will be carried into this branch afterwards. This supersedes my earlier note that the backport was ready.

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