[jilio]

This builds on #103 and contains its commit unchanged (9fb0223). Once #103 merges, this PR is the second commit only. If you'd rather take both together, merging this PR merges #103 too.

Problem

A 412 on the manifest CAS doesn't always mean another writer won. The S3 SDK retries in standard mode and GCS retries uploads that carry a precondition. So a CAS that lands but loses its reply gets 412 from its own write. #103 re-reads the manifest before dropping the segment on the push, compaction and settings paths. Two cases are still open:

1. The seal still deletes on any 412. seal_pack_replacement (classification.rs) still answers a 412 with drop_own_slot. The conserving pack lifecycle commits through it, so a landed seal answered 412 deletes the log segment the committed manifest lists. That is the same corruption Don't delete a committed log segment when the manifest CAS answers 412 #103 fixes: every later sync fails on the missing segment.
2. "Not listed" is not proof. A checkpoint folds the log at or past our seq (log_segments.retain(|s| s.last_seq > seq)) and drops our segment descriptor. If another instance commits and checkpoints between our landed CAS and our read-back, the manifest no longer lists us. Don't delete a committed log segment when the manifest CAS answers 412 #103 then deletes the committed (folded) segment and retries. The retry re-verifies the push against refs that already hold it, so the pusher is told Conflict { expected: "(new)", actual: <its own commit> } for a push that is durable.

Fix

slot_evidence reads the manifest and returns one of:

• Committed: our exact segment is listed (key, first seq, size, bytes).
• Unlisted: our key is not listed and no checkpoint is at or past our first seq, so no committed manifest ever listed it. With a 412 the request's precondition is gone for good, so the CAS provably lost.
• Unknown: the log was folded, our key is listed with other contents, or there is no manifest.

All four 412 paths (push, compaction, settings, seal) drop the segment only on Unlisted. Unknown keeps it and answers CommitUnknown, as D47 asks for missing evidence. The non-412 paths are unchanged (cas_landed now wraps slot_evidence).

Round trips are unchanged: still one manifest GET on the 412 path only, plus one log GET when our descriptor is listed. The ROUNDTRIPS row from #103 now names the seal and the folded rule.

Tests (each fails without this change)

• a_landed_seal_answered_412_keeps_the_commit (walgit-wal/tests/coverage.rs). On main and on Don't delete a committed log segment when the manifest CAS answers 412 #103 alone: manifest lists log/0000000000000002.pb but it is gone.
• a_landed_cas_folded_before_the_412_is_resolved_stays_unknown (walgit-wal/tests/wal.rs). A FaultStore gate holds the writer's read-back while a second instance pushes and checkpoints. On Don't delete a committed log segment when the manifest CAS answers 412 #103 alone the push is answered Ok([("refs/heads/main", Err(Conflict { expected: "(new)", actual: "84069d0…" }))]), which is its own commit, and its segment is deleted.
• only_an_unlisted_unfolded_segment_is_proven_uncommitted (unit, publish.rs) covers every evidence case.
• liveness_after_a_landed_cas_answered_412 (sim) is liveness_after_a_lost_cas_response with Don't delete a committed log segment when the manifest CAS answers 412 #103's p_cas_fail_after. On main: truth inconsistent after a landed CAS answered 412: object not found: repos/sim/r15/log/0000000000000002.pb.

Checked on Linux (Rust 1.97.1, git 2.47.3, 2-CPU container, non-root). This branch alone passes fmt, clippy (walgit-wal, walgit-store, walgit-server, all targets, -D warnings), the walgit-wal suites and the sim lost-response scenarios. just ci (warnings, clippy, test, e2e, sim, smoke) passes on a merge of this branch with my two other open fixes (#105, #106).

Same pattern, left alone here

These are safe, but worth knowing:

• A log-slot Create that lands and is answered 412 by a retry looks like another writer's orphan. The writer burns its own seq after the 300 ms grace and sweeps that segment after it commits.
• A lease acquire answered the same way waits out the TTL.
• Registry::create answered the same way reports AlreadyExists for the repository it just created.

🤖 Generated with Claude Code