Problem
When a workflow hits its max_iterations limit, the engine prompts the user via a console-only Rich IntPrompt. No event is emitted to the web dashboard's SSE stream, so the web UI shows the workflow as silently stalled — the last visible event is an agent_completed, then nothing.
This makes the iteration limit gate invisible to anyone monitoring via --web, which is the recommended way to monitor long-running workflows.
Root Cause
In engine/workflow.py (lines ~1964-1972), when MaxIterationsError is caught:
_suspend_listener() is called (pauses event streaming)
MaxIterationsHandler.handle_limit_reached() uses Rich's IntPrompt.ask() — console-only
- No
WorkflowEvent is emitted before or during the prompt
- The web dashboard has no corresponding event type in its
EventType union (web/frontend/src/types/events.ts)
Expected Behavior
- A new event type (e.g.,
iteration_limit_reached) should be emitted before the console prompt
- The web dashboard should render it as a gate-like UI showing:
- Current iteration count vs. limit
- Recent agent execution history (loop detection)
- Options: add more iterations, stop, or abort
- Ideally, the web dashboard should be able to resolve the gate (like human gates), not just display it
Impact
In practice, workflows with review loops (architect ↔ reviewer) can burn through iterations silently. The user monitoring the web dashboard sees the workflow go dark with no indication of what happened or what action is needed. They have to check the console terminal to discover the prompt, which defeats the purpose of --web.
Observed Scenario
A plan-child.yaml sub-workflow (invoked via for_each) looped between child_architect and child_reviewer for 20 iterations. The reviewer scored the plan 88/91 (above the 80 threshold) but kept setting approved: false. The iteration limit gate fired in the console but the web dashboard showed no indication — the workflow appeared frozen.
Suggested Event Schema
# New event type
emitter.emit(WorkflowEvent(
type="iteration_limit_reached",
data={
"current_iteration": current_iteration,
"max_iterations": max_iterations,
"agent_history": agent_history[-5:],
"possible_loop": len(set(agent_history[-3:])) <= 2,
}
))
Environment
- Conductor v0.1.9
- Web dashboard via
--web flag
Problem
When a workflow hits its
max_iterationslimit, the engine prompts the user via a console-only RichIntPrompt. No event is emitted to the web dashboard's SSE stream, so the web UI shows the workflow as silently stalled — the last visible event is anagent_completed, then nothing.This makes the iteration limit gate invisible to anyone monitoring via
--web, which is the recommended way to monitor long-running workflows.Root Cause
In
engine/workflow.py(lines ~1964-1972), whenMaxIterationsErroris caught:_suspend_listener()is called (pauses event streaming)MaxIterationsHandler.handle_limit_reached()uses Rich'sIntPrompt.ask()— console-onlyWorkflowEventis emitted before or during the promptEventTypeunion (web/frontend/src/types/events.ts)Expected Behavior
iteration_limit_reached) should be emitted before the console promptImpact
In practice, workflows with review loops (architect ↔ reviewer) can burn through iterations silently. The user monitoring the web dashboard sees the workflow go dark with no indication of what happened or what action is needed. They have to check the console terminal to discover the prompt, which defeats the purpose of
--web.Observed Scenario
A
plan-child.yamlsub-workflow (invoked viafor_each) looped betweenchild_architectandchild_reviewerfor 20 iterations. The reviewer scored the plan 88/91 (above the 80 threshold) but kept settingapproved: false. The iteration limit gate fired in the console but the web dashboard showed no indication — the workflow appeared frozen.Suggested Event Schema
Environment
--webflag