feat(staged): stream Blox workspace bootstrap progress to UI#497
feat(staged): stream Blox workspace bootstrap progress to UI#497
Conversation
Poll `sq blox ws commands <name> --json` for workspaces in "starting" state and emit `workspace-setup-progress` events so BranchCard can show which bootstrap step is running (starting services, running setup, or cloning repository) along with "Step X of Y" detail. Cloning is displayed as the final step since it tends to be the longest for most users. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Show the command_id alongside "Step X of Y" in the workspace setup progress detail so users can see which bootstrap command is running. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…s detail command_id is a numeric ID (e.g. "126977"), not a human-readable name. Use the phase label from bootstrap_phase_label instead so the detail reads e.g. "Step 1 of 3 · Cloning repository…". Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace ad-hoc phase label strings with stable identifiers matching the blox orchestrator proto CommandType enum (checkout, project_bootstrap, provision_workspace). Map these to human-readable display names in the UI to match the Blox web UI labels. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Show the command display name in the subtitle alongside "Step X of Y" (e.g. "Step 2 of 3 · Git checkout"). The main label stays as the generic "Starting workspace…". Also simplifies command selection to pick the first currently-running command rather than using a hardcoded sort order. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Move misplaced doc comment for poll_all_workspace_statuses to correct location above the function, separating it from bootstrap_command_type_name - Add safety comment explaining why the unwrap on current command is safe - Refactor emit_workspace_setup_progress to accept pre-filtered branch IDs instead of re-querying the store, using a HashMap<ws_name, Vec<branch_id>> built during the main iteration loop - Remove unused `unlisten` variable from BranchCard.svelte Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f520d32cdd
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| tauri::async_runtime::spawn_blocking(move || { | ||
| for (ws_name, branch_ids) in &starting_workspaces { | ||
| match blox::ws_commands(ws_name) { |
There was a problem hiding this comment.
poll_all_workspace_statuses now spawns a fire-and-forget spawn_blocking job on every poll while a workspace is starting, but this command is triggered repeatedly (the UI polls starting workspaces every 3s) and ws_commands itself can block up to the CLI timeout. Because these tasks are not awaited or deduplicated, slow sq blox ws commands calls can overlap and accumulate, causing unnecessary process/thread load and delayed UI responsiveness under normal startup delays.
Useful? React with 👍 / 👎.
1 participant
Summary
sq blox ws commandsintegration to fetch bootstrap command progress for starting workspacesworkspace-setup-progressevents from the polling loop so the frontend can show which bootstrap step is running (e.g. "Step 2 of 4 · Git checkout")BranchCard.svelteto listen for both local worktree and remote workspace progress events, and reset setup state when remote workspace reaches "running"Test plan
🤖 Generated with Claude Code