TXN undo bypass for MSET/multi-key DEL + abort-vs-recovery contradiction

[TinDang97]

From Lunaris RFC 0008 (https://github.com/pilotspace/lunaris/blob/main/docs/rfcs/0008-sharded-moon-ingest.md, §4.3), found while characterizing cross-shard TXN feasibility at v0.8.5: (1) MSET and multi-key DEL inside a TXN body bypass undo capture, so TXN.ABORT cannot roll them back; (2) the abort path and the WAL-recovery path disagree about the resulting state for the same interrupted transaction. Both are pre-existing single-shard defects, independent of sharding. File:line citations in the RFC §4.3.

[TinDang97]

Measured this against a v0.8.5 build (moon-dev, monoio, --shards 1 unless noted) while working #570. Two corrections to the issue text — one of the two claims in item (1) does not reproduce, and the one that does is worse than described.

MSET — reproduces, and it is a TORN rollback, not a skipped one

SET  ctl before               ; TXN BEGIN ; SET ctl after         ; TXN ABORT  ->  ctl = before   (control: OK)

MSET k1 B1 k2 B2 k3 B3 k4 B4  ; TXN BEGIN ; MSET k1 A1 .. k4 A4   ; TXN ABORT
  ->  k1='B1'  k2='A2'  k3='A3'  k4='A4'

Only the first key is restored. The transaction ends in a state that neither committed nor aborted — arguably worse than no rollback at all, because a caller that retries on TXN ABORT now retries against a half-written keyspace.

Creating keys is the same shape:

(empty)  ; TXN BEGIN ; MSET n1 X1 n2 X2 n3 X3 ; TXN ABORT
  ->  EXISTS n1 n2 n3 = 2

An aborted transaction left behind two keys it created.

At --shards 4 with the keys co-located by {hash} tag (the configuration the ERR_TXN_CROSS_SHARD guard tells operators to use), nothing is rolled back:

MSET {t}:a B1 {t}:b B2 ; TXN BEGIN ; MSET {t}:a A1 {t}:b A2 ; TXN ABORT
  ->  {t}:a='A1'  {t}:b='A2'

Root cause is visible in the capture site (handler_monoio/mod.rs ≈2645, twin in handler_sharded/mod.rs ≈2020): the undo-log capture special-cases DEL/UNLINK (all args) and otherwise falls back to extract_primary_key, which returns exactly ONE key. MSET's keys are at args[0], args[2], args[4], …, so keys 2..N are never captured. At --shards > 1 MSET is additionally intercepted by is_multi_key_command → coordinate_multi_key before it ever reaches the capture, which is why the tagged case captures nothing at all.

multi-key DEL — does NOT reproduce

MSET e1 V1 e2 V2 e3 V3 e4 V4 ; TXN BEGIN ; DEL e1 e2 e3 e4 ; TXN ABORT
  ->  EXISTS e1 e2 e3 e4 = 4      (all four restored)

The DEL/UNLINK arm of the capture iterates every argument, so it is covered. Either this was fixed since the RFC was written, or the RFC's §4.3 citation refers to a path this probe does not reach. Worth re-checking against the RFC's exact line references before any work is scoped.

Item (2) — not investigated

The abort-vs-recovery contradiction is specified in RFC 0008 §4.3 in pilotspace/lunaris, which I could not read. It needs the RFC's file:line citations to be actionable, and it is a specification disagreement (which state is correct?) rather than a bug with an obvious right answer.

Suggested direction for item (1)

Undo capture should use the command's full key spec instead of extract_primary_key. #583 just landed a shared key-position walker (acl::keyspec) that already understands MSET's step-2 layout, numkeys vectors, the STREAMS token and positional STORE clauses — pointing the capture at that walker fixes MSET and every other multi-key write in one change, rather than adding a second hand-maintained special case beside the DEL one.

Two things that must be settled first, because they change the shape of the fix:

1. Coordinated commands bypass the capture entirely. MSET/MSETNX/BITOP/COPY/multi-key DEL are routed to coordinate_multi_key before the local-dispatch block that owns the undo capture. Fixing the key walker alone does not help them; the capture has to move upstream of that branch, or the branch has to capture for itself.
2. TXN.COMMIT's dirty-abort message already documents this hole (err_txn_commit_dirty in command/transaction.rs: "rolled back and NOT committed", deliberately not "nothing was applied", citing this issue). That wording can only be strengthened once the capture is complete.

Any fix here needs the crash/durability gates, not just unit tests: an undo log that is more complete but wrong under kill -9 mid-abort is a regression the current honest-but-incomplete behaviour does not have.