Stop re-logging a replicated delete that is re-delivered onto its own tombstone (#2761 → v5.2)

[kriszyp]

Backport of #2761 to v5.2: a replicated delete that is re-delivered onto the tombstone it already left is no longer applied and logged again (#1162).

When a delete is delivered again with the same version and origin, the key already holds the tombstone it left. _writeDelete used to skip only a strictly older write, so a tie re-applied and appended a fresh audit entry on every delivery. In a mesh each copy is new log tail that every peer forwards and re-logs in turn. Now such a delete returns without writing. It still stages the removal, so later writes in the transaction see the key as removed.

For the human reviewer

1. Requirement: port Stop re-logging a replicated delete that is re-delivered onto its own tombstone #2761 closely. v5.2 has the in-transaction staged-write chain (priorStagedWrite, stagedEntry, priorWrite), so this keeps main's removalBefore walk:

   • it uses the nearest earlier write in the transaction that staged state, otherwise the stored entry;
   • it passes over writes marked skipped;
   • it never treats an invalidation stub as a removal.

   v5.2 has neither isAuditEntryWrite nor a transaction-log key separate from the version. So the identity check is isSameRemoval: no record, the same version as this transaction, and the same origin id.

2. A retried commit repeats its first round's decision. On an ERR_BUSY recommit the kept write batch shows this write's own round-one tombstone as the existing entry, and conflict recovery depends on writing the key again. The Stop re-logging a replicated delete that is re-delivered onto its own tombstone (#2761 → v5.1) #2813 review flagged this for v5.1, and the same fix is applied here.

3. A local delete's origin compares as 0, which is the id this node's own name is pinned to. The node-id map is not read on every delete.

4. Test note. main's replicatedDeleteRedelivery.test.js is ported unchanged. Two of its cases pass a version option that this line doesn't read ("reuses the tombstone version under a new log key", "shares its version with the live record"), so on v5.2 they never produce a version tie.

Changes

• resources/Table.ts, _writeDelete:
  • the re-delivery guard, with the staged removal and the retry decision;
  • removalBefore, from main;
  • isSameRemoval.
• unitTests/resources/replicatedDeleteRedelivery.test.js: ported from main.

Verification

• The ported test passes 16 of 16 here. On unmodified v5.2, 6 fail.
• npm run test:unit:resources: 1807 passing.

Complexity: medium

🤖 Generated with Claude Code

_{Review-Coverage: authored=claude; ran=codex,gemini; adjudicated=domain; blocked=cursor-composer(auth); declined=cursor-grok,cursor-kimi,cursor-muse; rounds=1; full=1 @ 7123cf9}

_{Human-Review-Need: 3 (decisions: dedup-by-tombstone-identity, carry-first-round-decision-on-retry, receiver-side-idempotency-vs-relay-fix) @ 74ad415}

[gemini-code-assist]

Code Review

This pull request prevents replicated deletes that are re-delivered onto the state they already produced from being re-logged. It introduces a check in resources/Table.ts to detect redelivered deletes, marking them as skipped and returning early to avoid appending redundant audit entries. Additionally, a comprehensive test suite is added in unitTests/resources/replicatedDeleteRedelivery.test.js to verify various scenarios of redelivered deletes. There are no review comments, so we have no feedback to provide.