In short: an agent passed as planner= gets no workers started for its tools, so its tasks sit in the queue with nothing polling them and the example hangs forever.
Files: src/conductor/ai/agents/runtime/runtime.py; reproduced by examples/agents/86_coding_agent.py
Symptom
$ python examples/agents/86_coding_agent.py
Hangs forever, no output after the worker banner. Output at 180s and 300s is byte-identical — no progress. Still reproduces on Orkes Conductor 5.5.0 against main at 8ff5f88f (240s, no progress).
Cause
Workers start only for the parent agent's tools=. Tools declared on the agent passed as planner= get none, so the planner's read_file tasks stay SCHEDULED with nothing polling them.
grep -n '\.planner' runtime.py matches only comments — no code reads that slot when collecting worker tools._ensure_models_for_agent walks a.agents recursively, so the old form was covered.- The named slots
planner= / fallback= replaced the older agents=[planner, fallback] form, and the traversal was never extended to them.
Fix
Collect worker tools through planner= and fallback=, not only agents=.
Verify
python examples/agents/86_coding_agent.py reaches the planner and stops hanging. Confirmed: supplying those four workers from a second process ends the hang (128s vs indefinite).
Notes
This does not make 86 pass. It then fails with No JSON plan found and no fallback agent configured, a separate defect.
Reproduce on Orkes Conductor 5.5.0, not OSS 3.32.0. On OSS 3.32.0 the example no longer reaches this hang — it fails first, at 42s, with a separate defect that masks this one:
Plan compilation failed: Validation 0 has unsafe success_condition:
unexpected trailing input: '('passed') >= 0' at position 9 in: $.indexOf('passed') >= 0
No other example is known to expose this. 115_plan_execute_planner_context.py and adk/24_planner.py both use planner= but cannot reach it, and both pass:
115's planner declares the same four tools as its parent harness, so the parent's tools= already starts those workers.adk/24_planner.py passes BuiltInPlanner(...), which carries no tools at all.
In short: an agent passed as
planner=gets no workers started for its tools, so its tasks sit in the queue with nothing polling them and the example hangs forever.Files:
src/conductor/ai/agents/runtime/runtime.py; reproduced byexamples/agents/86_coding_agent.pySymptom
Hangs forever, no output after the worker banner. Output at 180s and 300s is byte-identical — no progress. Still reproduces on Orkes Conductor 5.5.0 against
mainat8ff5f88f(240s, no progress).Cause
Workers start only for the parent agent's
tools=. Tools declared on the agent passed asplanner=get none, so the planner'sread_filetasks stay SCHEDULED with nothing polling them.grep -n '\.planner' runtime.pymatches only comments — no code reads that slot when collecting worker tools._ensure_models_for_agentwalksa.agentsrecursively, so the old form was covered.planner=/fallback=replaced the olderagents=[planner, fallback]form, and the traversal was never extended to them.Fix
Collect worker tools through
planner=andfallback=, not onlyagents=.Verify
python examples/agents/86_coding_agent.pyreaches the planner and stops hanging. Confirmed: supplying those four workers from a second process ends the hang (128s vs indefinite).Notes
This does not make
86pass. It then fails withNo JSON plan found and no fallback agent configured, a separate defect.Reproduce on Orkes Conductor 5.5.0, not OSS 3.32.0. On OSS 3.32.0 the example no longer reaches this hang — it fails first, at 42s, with a separate defect that masks this one:
No other example is known to expose this.
115_plan_execute_planner_context.pyandadk/24_planner.pyboth useplanner=but cannot reach it, and both pass:115's planner declares the same four tools as its parent harness, so the parent'stools=already starts those workers.adk/24_planner.pypassesBuiltInPlanner(...), which carries no tools at all.