fix: make stop agent button immediately kill running agent by joshjon · Pull Request #177 · vervesh/verve

joshjon · 2026-03-13T02:45:37Z

Summary

Stop agents button now integrated with a dedicated stop-poll channel so workers receive stop signals immediately with O(1) connection overhead. Additionally, epic planning agents had no stop mechanism — this adds one mirroring the task pattern.

Changes

Add poll-based stop delivery: workers long-poll GET /agent/poll?accept=stop via a dedicated stopPollLoop goroutine, receiving task and epic stop signals immediately
- Replace WatchStop/UnwatchStop/notifyStop in task.Store with a stop queue (queueStop/WaitForStop/DrainStops)
- Simplify TaskHeartbeat to a simple request/response ping (no long-polling); stopped field retained as
  safety net
- Add StopEpic to epic.Store: validates planning+claimed state, appends session log, releases claim, sets draft status
- Add POST /epics/:id/stop endpoint and wire through to UI with a "Stop Planning" button
- Enhance EpicHeartbeat to return JSON with stopped field instead of 204
- Add worker context tracking (runningCtxs) so stop signals cancel running containers immediately
- Add tests for stop queue, poll-based stop delivery, epic stop, and simplified heartbeat

The heartbeat endpoint now uses long-polling: when a task is still running, the server holds the connection for up to 4 seconds waiting for a stop signal. When StopTask is called, it immediately notifies the held heartbeat request via an in-process channel, causing the worker to cancel the agent container within milliseconds instead of waiting up to 5 seconds for the next polling cycle. Changes: - Add WatchStop/UnwatchStop/notifyStop to task.Store for in-process stop signal propagation - Convert heartbeat handler from immediate-response to long-polling with configurable hold duration (4s default) - StopTask now closes the stop channel to wake any waiting heartbeat Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>