Files
buzz/desktop/src-tauri
npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 c2f2f9a833 fix(desktop): force-claim before scope resolution; propagate base-dir errors
IMPORTANT#1: move force_claim_in_progress() before active_retention_scope()
in both workspace.rs and identity.rs. On scope-resolution failure the claim
now drops via RAII → Unready, so the flush loop can retry. Previously a
transient scope failure after a key/relay swap left the stale Ready(old_path)
latch alive; claim_in_progress rejects from any Ready state, so publication
was permanently stopped for the session.

New test: test_scope_resolution_failure_after_force_claim_leaves_latch_unready_and_retryable
covers Ready(A) → swap → scope failure → Unready → retry claims and runs the
full transition for scope B.

IMPORTANT#2: replace let Ok(base_dir) = managed_agents_base_dir(app) else { return Ok(()) }
with let base_dir = managed_agents_base_dir(app)? in all three reconcile
wrappers (migrate_personas_to_events, migrate_teams_to_events,
reconcile_agents_to_events). Base-dir failures now propagate through
run_event_sync's Result; a failed leg cannot silently certify Ready.

New test: test_base_dir_failure_propagates_through_run_event_sync drives the
new run_event_sync_in_dir seam with a bad db_path, asserts Err returns and
scope stays Unready, then proves the full retry with a valid path enqueues
the row and certifies Ready.

MINOR: rewrite config_barrier.rs enforcement comment to state the real
invariant — managed_agents_store_lock does NOT freeze the readiness
generation; force_claim_in_progress takes only the readiness mutex. A
preempted force-claim sets InProgress on a new generation and its own
barrier (or a full flush retry) supplies the final gate writes.

Prose nits: fix flush_barrier_tests.rs:216 reference to deleted
run_boot_barrier; fix identity.rs comment that referenced is_ready_for
(now #[cfg(test)]) — flush uses readiness_state() directly.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
2026-08-01 14:09:31 -04:00
..