spawn_parallel_agents: opt out of the 120s per-tool timeout so the fan-out isn't truncated

[M3gA-Mind]

Bug #2 — 120s truncation (root-caused + fixed here)

Every OpenHuman tool is wrapped in tokio::time::timeout(deadline, exec) (tinyagents/tools.rs), where deadline for the default ToolTimeout::Inherit is the global per-tool wall-clock (tool_timeout DEFAULT_TIMEOUT_SECS = 120). SpawnParallelAgentsTool never overrode timeout_policy, so the entire fan-out was hard-killed at 120s — the parent span's exact 120.000s — truncating every worker and bounding the group at one worker's budget instead of ~the slowest.

Fix: override timeout_policy → ToolTimeout::Unbounded, matching the long-running scripting tools (shell, node_exec, rhai_workflows). The fan-out is already bounded internally — by its max_concurrency, the run cancellation token, and each sub-agent's own iteration/turn caps — so it governs its own lifetime rather than the single-tool default. Adds a unit test.

Bug #1 — serialization (investigated; not an OpenHuman fan-out bug)

The fan-out already runs concurrently: run_spawn_parallel_workers calls tinyagents::graph::parallel::map_reduce with max_concurrency = prepared.len() over buffer_unordered (concurrent since #4249). The serial fallback only triggers for shared-workspace write workers — read-only research never hits it; run_queue is None; and the managed (OpenAI-compatible) provider has no client-side concurrency semaphore. So OpenHuman does not request serial execution. The observed strict serialization isn't reproducible from any OpenHuman fan-out line — the likely causes are the 120s parent-timeout aborting the concurrent fan-out (removed by this PR) or server-side per-token serialization in the managed backend. I deliberately avoided a speculative concurrency change since concurrency is already max_concurrency=N.

Note / follow-up

Each worker's own model call and inner tools still inherit the global 120s (tool_timeout + inference request_timeout). Making those higher or research-tier-configurable is a separate global-config/design decision, flagged rather than bundled here.

Prompt-independent from #4680 (that fix was orchestrator-prompt-only and does not touch this execution path).

Closes #4685

Summary by CodeRabbit

• Bug Fixes

  • Improved reliability for parallel agent spawning by allowing this operation to run without the standard per-tool time limit, reducing unexpected timeouts during larger fan-out tasks.

• Tests

  • Added coverage to verify the parallel agent spawning behavior is not constrained by the global tool timeout.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ed1af5f9-75cd-40aa-a89b-f9647c73b16f

📥 Commits

Reviewing files that changed from the base of the PR and between 89d601c and d8e8a6a.

📒 Files selected for processing (2)

• src/openhuman/agent_orchestration/tools/spawn_parallel_agents.rs
• src/openhuman/agent_orchestration/tools/spawn_parallel_agents_tests.rs

---

📝 Walkthrough

Walkthrough

SpawnParallelAgentsTool now implements a timeout_policy method returning ToolTimeout::Unbounded, exempting the tool from the global per-tool wall-clock timeout. A new unit test verifies this behavior.

Changes

Spawn Parallel Agents Timeout Override

Layer / File(s)	Summary
Unbounded timeout policy src/openhuman/agent_orchestration/tools/spawn_parallel_agents.rs	Imports ToolTimeout and adds a timeout_policy method returning ToolTimeout::Unbounded to disable the global timeout for this fan-out tool.
Test coverage src/openhuman/agent_orchestration/tools/spawn_parallel_agents_tests.rs	Imports ToolTimeout and adds a test asserting timeout_policy returns ToolTimeout::Unbounded.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related PRs

• tinyhumansai/openhuman#4262: Updates run_agent_tool_call to honor each tool's timeout_policy, directly consuming the override added here.

Suggested labels: agent

Poem

A rabbit hops with timer freed,
No 120-second cap to heed,
Parallel workers run and race,
Unbounded now, they find their pace,
Hop hop hooray, the fan-out's fast indeed! 🐇⏱️

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR fixes the timeout truncation, but it does not address the linked issue’s sequential fan-out/concurrency bug.	Investigate and fix the spawn_parallel_agents execution path so workers run concurrently, then keep the timeout change if still needed.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: opting out of the 120s timeout for spawn_parallel_agents.
Out of Scope Changes check	✅ Passed	The changes stay focused on spawn_parallel_agents timeout behavior and its test, with no obvious unrelated additions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

_{Comment @coderabbitai help to get the list of available commands.}

[M3gA-Mind]

CI + review pass — LGTM.

Reviewed origin/main...HEAD. The fix overrides SpawnParallelAgentsTool::timeout_policy to ToolTimeout::Unbounded, removing the global 120s per-tool wall-clock cap that this fan-out primitive was silently inheriting (default ToolTimeout::Inherit) — which truncated every worker and bounded the whole group at one worker's budget. Verified:

• Correct/minimal: a single timeout_policy override + import + unit test.
• Matches the established pattern: shell, node_exec, npm_exec, and plan_review all opt out the same way (-> ToolTimeout::Unbounded, documented as 'no harness-imposed deadline').
• No safety bound removed: the fan-out is still bounded internally — the task count is capped at max_parallel_tools (enforced with an error in spawn_parallel_graph), concurrency is bounded by map_reduce/ParallelOptions, the run CancellationToken still applies, and each sub-agent keeps its own iteration/turn caps. The 120s cap was inappropriate for a group primitive, not a needed guard.
• Test present + valid: asserts timeout_policy(&json!({})) == ToolTimeout::Unbounded (enum derives PartialEq, so it compiles) and passes in CI.

Checks: cargo check --lib ✓ clean compile, cargo fmt --check ✓; GitHub CI green — Rust Quality (fmt, clippy), Rust Core Coverage (runs the new test), and the rest all pass (10/10, 5 skipped as not-applicable). No fix needed.