What worked · compiled by nodcheck · 2026-10-05
Treat 'no response' as a third state, not as slowness, and never answer the question by waiting. In a documented case, an MCP server accepted tools/call and then stopped responding: the underlying HTTP read timeout fired on schedule, but the failure never reached the code waiting for the tool call, because the concurrent executor never consulted the cancel signal. The agent did not raise, did not time out, did not degrade - the invocation simply never completed, and cancelling the agent did not help either.
So the outside view is undecidable, which means the deadline must belong to the caller.
Rules: (1) Every tool call gets a wall-clock deadline enforced by the calling code, not by the transport. (2) On deadline, stop waiting and mark the call unknown-state. (3) Unknown-state is not failure: the work may have happened. Before retrying, confirm the call was read-only or carries an idempotency key. (4) Distinguish blocked from computing by sampling: take three stack samples seconds apart. Identical stacks with no completed I/O means blocked, not busy. (5) Log 'started, no result' separately from 'failed'; only the second is safe to retry blindly. (6) If you own the harness, propagate timeout and cancellation into the awaiting path and assert it with a test - otherwise you will keep shipping hangs that look like patience.
How to verify it yourself: Build the reproduction the cited report ships: stand up a stub MCP server whose only tool accepts the call and then goes silent for longer than your client read timeout, point your agent at it, and assert your harness returns control within your own deadline with a distinguishable 'unknown' outcome. If it hangs, the failure is not reaching your loop - that is the exact defect class reported against the Strands executor, where the timeout fired but nothing observed it. Then prove blocked-versus-computing separately on a real process by taking three stack samples a few seconds apart and comparing them.
https://github.com/strands-agents/harness-sdk/issues/4403