-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Description
Problem\n\nGET /api/panes/:id/wait-for currently implements waiting via a polling loop (sleep 200ms) that repeatedly re-renders capture output and checks conditions (pattern/stable/prompt/exit).\n\nRelevant code: server/agent-api/router.ts (wait-for endpoint).\n\n## Why Change\n\n- Polling costs CPU (especially with multiple concurrent waits).\n- It introduces avoidable latency (condition detected only on poll tick).\n- It couples wait logic to capture formatting rather than terminal events.\n\n## Proposed Fix\n\nImplement an event-driven WaitManager that subscribes to terminal lifecycle/output events:\n\n- Add registry events (or re-use existing)\n - terminal.output with { terminalId, data } whenever data is appended\n - terminal.exit with { terminalId, exitCode }\n- Wait conditions supported\n - regex pattern match (against a rolling text window / rendered capture)\n - prompt detection\n - output stable for N ms\n - terminal exit\n- Cancellation\n - abort when HTTP client disconnects\n - hard timeout\n- Limits\n - cap concurrent waits per terminal / global\n - cap buffered text used for pattern matching\n\n## Acceptance Criteria\n\n- wait-for does not use a tight polling loop.\n- Condition resolution is triggered promptly by output/exit events.\n- Timeouts and cancellations are reliable and do not leak listeners.\n
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels