dave/storkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity

story-kit: create 149_bug_web_ui_does_not_update_when_agents_are_started_or_stopped

Browse Source
This commit is contained in:
Dave
2026-02-24 18:20:36 +00:00
parent 4efe00f5b3
commit c00fc10485
1 changed files with 13 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
.story_kit/work/1_upcoming/149_bug_web_ui_does_not_update_when_agents_are_started_or_stopped.md
View File

@@ -8,6 +8,10 @@ name: "Web UI does not update when agents are started or stopped"
Agent start/stop changes are in-memory HashMap mutations in the agent pool. No WatcherEvent is emitted for these changes, so the WebSocket never pushes an update to the frontend. The agent panel only refreshes on its polling interval, meaning agent swaps and new agent starts are invisible until the next poll. Agent start/stop changes are in-memory HashMap mutations in the agent pool. No WatcherEvent is emitted for these changes, so the WebSocket never pushes an update to the frontend. The agent panel only refreshes on its polling interval, meaning agent swaps and new agent starts are invisible until the next poll.
Additionally, when an agent is assigned to a work item (e.g. a coder starts on a story), the pipeline board should reflect the change immediately — the work item should go from amber (unassigned) to green (agent working). Currently this requires a full page refresh.
The key insight is that agent assignment is an in-memory event, not a filesystem event, so the watcher won't catch it. The server needs to push agent state changes over WebSocket explicitly.
Fix options: Fix options:
1. Emit a WatcherEvent (e.g. AgentStateChanged) when start_agent/stop_agent modifies the pool, and have the WebSocket handler forward it to the frontend 1. Emit a WatcherEvent (e.g. AgentStateChanged) when start_agent/stop_agent modifies the pool, and have the WebSocket handler forward it to the frontend
2. Or have the frontend subscribe to a dedicated agent-state WebSocket message type 2. Or have the frontend subscribe to a dedicated agent-state WebSocket message type
@@ -16,21 +20,24 @@ Key files:
- server/src/agents.rs: start_agent / stop_agent — where the state change happens - server/src/agents.rs: start_agent / stop_agent — where the state change happens
- server/src/http/ws.rs: WebSocket handler that could forward agent state events - server/src/http/ws.rs: WebSocket handler that could forward agent state events
- frontend/src/components/AgentPanel.tsx: polling-based agent list refresh - frontend/src/components/AgentPanel.tsx: polling-based agent list refresh
- frontend pipeline board: wherever work item color (amber/green) is derived from agent assignment
## How to Reproduce ## How to Reproduce
1. Open the web UI and look at the Agents panel 1. Open the web UI and look at the pipeline board
2. Start or stop an agent via MCP (e.g. start_agent or stop_agent) 2. Start an agent on a story via MCP or the API
3. Observe the Agents panel 3. Observe the pipeline board — the work item stays amber until a full page refresh
## Actual Result ## Actual Result
Agent panel does not update until the next polling interval. Starting or stopping agents is invisible in real-time. Agent panel and pipeline board do not update until the next polling interval or a full page refresh. Starting/stopping agents and agent assignment to work items are invisible in real-time.
## Expected Result ## Expected Result
Agent panel should update immediately when agents are started or stopped. Agent panel and pipeline board should update immediately when agents are started, stopped, or assigned to work items.
## Acceptance Criteria ## Acceptance Criteria
- [ ] Bug is fixed and verified - [ ] Agent start/stop events are pushed over WebSocket to the frontend
- [ ] Pipeline board work items update color (amber → green) immediately when an agent is assigned
- [ ] No full page refresh required to see agent state changes