Commit Graph
1 Commits
Author SHA1 Message Date
Omar SobhandClaude Opus 4.7 e929a6f32f Phase 4d: WAL replay engine
Build with clawstor cache / Cargo build (clawstor-cached) (pull_request) Successful in 10s
Given a peer connection + a decoded WalMutation, re-issue the
correct RPC. Closes the loop from "durably logged at client"
to "actually applied at peer" on reconnect.

Outcome classification is deliberate:
  * Applied    — peer accepted the mutation.
  * Superseded — peer already had a dominant version, or the
                 delete target was absent. NOT a failure; the
                 mutation's intent matches current peer state.
  * Err(_)     — genuine RPC failure; caller retries later.

Both Applied and Superseded advance the watermark past the
record — the WAL can safely truncate.

Public surface:
  ReplayOutcome { Applied | Superseded }
  replay_one(&conn, &mutation) -> Result<ReplayOutcome>
  drive_replay(&conn, &wal, start_seq) -> Result<DriveReport>
  DriveReport { last_applied, applied, superseded,
                skipped, stopped_at: Option<(seq, msg)> }

drive_replay stops on the first hard error and returns
last_applied so the caller can `wal.truncate_up_to(...)`
before closing. Undecodable/unknown-kind records mid-stream
are skipped (with warn!) rather than aborting — otherwise
one bad record would jam an otherwise-good tail forever.

Tests (4, all green, end-to-end over QUIC):
  * every variant round-trips; peer state verified via
    call_get_ref / call_get_tag_versioned / call_get_tag_expiry
  * versioned-reject counts as Superseded, not Err
  * DeleteTag on a missing key is Superseded
  * undecodable record between two real mutations is skipped;
    both good records still apply; last_applied advances past
    the skip

434 lines, well under the 1300 ceiling.

Co-Authored-By: Claude Opus 4.7 <[email protected]>
2026-07-14 01:03:46 -07:00