mirror of https://github.com/block/buzz.git synced 2026-08-18 06:50:31 +02:00

Files

T

DuncanandWill Pfleger 9bac71b65b fix(workspace): represent applied-but-blocked as a truthful third state

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>

2026-08-06 19:00:21 -04:00