mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
DuncanandWill Pfleger
9bac71b65b
Provider-access reconciliation runs in the post-commit section of apply_workspace, after relay/keys/scope have committed. The previous .await? propagated any reconciliation failure as a command Err, causing the frontend to treat the workspace as unapplied and clear appliedKey — while the new scope was already active. This contradicted the applied/degraded contract and the useCommunityInit error-handling assumption. Fix: replace .await? with a match that returns WorkspaceApplyResult with applied: true and blocked: Some(reason) on reconciliation failure. Dependent post-commit steps (event sync, agent restore) remain unreached on this path, preserving #4053's fail-closed intent. The frontend parks on the loading gate with a truthful error and the same retry-by-reapply semantics as the catch block. Changes: - scope.rs: add blocked: Option<String> field to WorkspaceApplyResult, add applied_but_blocked() constructor, document the three states - workspace.rs: replace .await? with match; return applied_but_blocked on reconciliation failure; update command doc comment - useCommunityInit.ts: handle blocked after the !applied branch; update catch-block comment (reconcile failures no longer arrive as Err) - tauri.ts: add blocked?: string | null to ApplyWorkspaceResult type - e2eBridge.ts: add blocked: null to apply_workspace mock result - runtime_commands_tests.rs: add three new tests covering the new state and the three-state distinction Co-authored-by: Will Pfleger <pfleger.will@gmail.com> Signed-off-by: Will Pfleger <pfleger.will@gmail.com>