mirror of
https://github.com/block/buzz.git
synced 2026-11-04 16:31:38 +00:00
6c2d26e884
A preempted ReadinessClaim had no ownership identity: after force_claim_in_progress() seized the latch from a flush-owned InProgress, the flush's in-flight barrier could still call complete()/drop and unconditionally mutate the latch. Two legs: - Leg 1 (same-scope case): stale flush barrier finishes, calls resolve()+mark_ready() → latch certified Ready while reconcile was still retaining rows → stale rows publish unarbitrated. - Leg 2: stale barrier errors → RAII drop resets force-claim's InProgress to Unready mid-migration → next flush tick wins a fresh claim and certifies against mid-sequence state. - Leg 3: run_boot_barrier_for_scope's abandon arm returned Ok(()) which the enforcing wrapper treated as Success. Fix: the latch carries a u64 generation counter. force_claim_in_progress increments it; claim_in_progress records the current generation. Latch mutations move onto the claim: - claim.complete(db_path) → Ready only if latch generation matches. - Drop → Unready only if generation matches. - Preempted claims are silent no-ops in both paths. BarrierOutcome enum added; abandon arm returns Abandoned (not Success) so run_boot_barrier_enforcing never calls complete() for an abandoned scope. mark_ready() and resolve() removed from the public API; mark_unready() gated to #[cfg(test)] since all production transitions now go through the claim. Tests (g)/(h): stale complete/drop are no-ops after force-claim. Test (i): leg-1 end-to-end interleaving — stale barrier complete cannot certify Ready; rows retained after the stale complete cannot publish until force-claim's own barrier passes. Tests (c)/(e)/(f) updated to claim.complete() API. Co-authored-by: Will Pfleger <pfleger.will@gmail.com> Signed-off-by: Will Pfleger <pfleger.will@gmail.com>