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

[call-me-ram]

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.

[harshitwandhare]

No comments on this since it was filed, so here is where it stands on main at 29b235cf. Two things have moved under it.

The synchronous create path got a padded timeout two days after this was filed

_HANDOFF_CREATE_TIMEOUT_S = 150.0 landed in 4f1b8f16 (#634, 2026-09-01). This issue measured 231de7a4 on 08-30, before it existed. handoff's early-terminal-id path passes it at orchestration.py:1236, so that call is no longer sitting at 30s.

assign passes defer_init=True (orchestration.py:1563), and the code there says the server returns as soon as the tmux window is up with init running as a background task, so the 30s default is not the binding constraint on that path either. I have not timed a live assign, so I am taking that from the code rather than from a measurement.

What is left is the "fix shape" paragraph above: it is a second hard-coded constant, and it does not track the setting

Measured on main, varying CAO_PROVIDER_INIT_TIMEOUT and computing each provider's real ready timeout from its own floor (antigravity_cli.py:661 180.0, kimi_cli.py:621 120.0, minimax_code.py:466 120.0):

operator sets  effective   antigravity  kimi     minimax   worst   client  verdict
init_timeout   read back   max(180,i)   (120)    (120)             150.0
        60          60        180.0     120.0    120.0    180.0    150.0   client gives up first
       120         120        180.0     120.0    120.0    180.0    150.0   client gives up first
       180         180        180.0     180.0    180.0    180.0    150.0   client gives up first
       240         240        240.0     240.0    240.0    240.0    150.0   client gives up first
       300         300        300.0     300.0    300.0    300.0    150.0   client gives up first
       600         600        600.0     600.0    600.0    600.0    150.0   client gives up first

The client constant is flat down every row. An operator who raises provider_init_timeout to give a slow provider more room gets no more room on the client side, which is the drift this issue predicted.

How this sits with #773

#773 is open and unreviewed and raises the constant to 240.0. That clears the first three rows and leaves the last two, so it fixes the shipped-default case without addressing the drift. The two are compatible rather than competing: #773 is a correct immediate fix for the defaults, and deriving the value would remove the constant it is raising.

What I would send, if you want it

Replace _HANDOFF_CREATE_TIMEOUT_S with a read of provider_init_timeout plus a stated margin, floored so the default settings keep today's behaviour. One source of truth, and a provider arriving with a higher floor stops being a silent regression.

The part I cannot decide from the code is what the margin has to cover. The per-provider floors are max(180, init) and max(120, init), applied inside each provider, and the create call does not know which provider it is about to start. Covering the worst known floor means hard-coding 180 in a second place, which is the problem again; covering only init leaves the default-settings case short, which is what #773 is fixing. A lookup from profile to provider floor would settle it but does not exist today.

So the shape is clear and the constant is not mine to choose. If you name which of those you want, I will build it with tests. If you would rather take the simple bump in #773 and close this, that is a reasonable outcome too and I will not duplicate it.