awslabs / awslabs/cli-agent-orchestrator

MCP tool calls time out at 30s while provider init is allowed 60s+ — successful handoffs report failure

Open
#710 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.