awslabs / awslabs/cli-agent-orchestrator
MCP tool calls time out at 30s while provider init is allowed 60s+ — successful handoffs report failure
- Dominant language
- Python
- Stars
- 1.3k
- Forks
- 267
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 70
Description
### Summary
Every MCP-server HTTP call to the CAO API uses `MCP_REQUEST_TIMEOUT = 30` (`constants.py:370`, consumed at `mcp_server/utils.py:53`), but the handoff/assign endpoints internally wait up to `server.provider_init_timeout` — default **60** (`config_service.py:59`) — for the worker's provider to initialize. Any provider that takes between 30s and its init budget to come up (perfectly successful init) has the MCP-side request abort first: the supervisor's tool call fails with a timeout while the server goes on creating the worker, so the caller retries against a worker that already exists, or gives up on a handoff that actually succeeded.
The mismatch is strictly worse for the slower providers — several ship init budgets in the hundreds of seconds (antigravity, kimi, kiro) while the transport above them still gives up at 30.
### Credit
Diagnosed by @reyph in #463 ("Bug 1"). That PR went quiet before the review round completed, so the finding is being re-filed standalone so it isn't lost with the PR. Verified still live on `main` at `231de7a4`.
### Fix shape
The one-line version is raising `MCP_REQUEST_TIMEOUT` above the worst-case init budget, but a value pulled from settings would be better: the per-call timeout for session-creating tools should be derived from (and strictly greater than) `server.provider_init_timeout` rather than a second hard-coded constant that can drift. Non-session-creating calls (status reads, message sends) are fine at 30.
Related: #453 explored the durable-result direction for the transport-timeout family; #566 (merged) fixed the sibling client-side drop at launch.
Contributor guide
Research direction
Start by tracing MCP_REQUEST_TIMEOUT in constants.py:370 and mcp_server/utils.py:53, then compare it with server.provider_init_timeout from config_service.py:59 and the handoff/assign endpoints. Done means session-creating calls wait beyond provider initialization while status reads and message sends retain the 30-second limit, preventing successful handoffs from being reported as failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100