Repository navigation
fix(mcp): enforce wall-clock timeout for test runs - #1766
Conversation
Closes #1765 Co-authored-by: ryzizub <ryzizub@users.noreply.github.com>
|
@vgvbot two changes before this can merge. 1. Kill the run, don't just abandon it. After the budget elapses There is a path for it: 2. |
Co-authored-by: ryzizub <ryzizub@users.noreply.github.com>
|
/unicoder address the comments on the PR |
Co-authored-by: erickzanardo <erickzanardo@users.noreply.github.com>
📊 Cognitive Complexity AnalysisNet Delta: +5 | Added: 2 | Increased: 3 | Improved: 2 | Removed: 0 | Violations: 0
|
|
/unicoder address the last comment on the PR |
Co-authored-by: erickzanardo <erickzanardo@users.noreply.github.com>
Fixes #1765
Summary
The MCP
testtool'stimeout_secondsparameter was forwarded as--timeouttoflutter test, which implements a per-test timeout that doesn't fire when a test awaits a future that never completes (e.g., intester.runAsync). This caused hung tests to block the MCP server indefinitely since tool runs are serialized with a lock.Changes
Wall-clock timeout enforcement:
timeout_secondsis now enforced as a hard limit on the entire tool run in_runToolCommandusingFuture.timeout. When exceeded, the tool immediately returns a timeout failure, releasing the server lock so queued calls can proceed.Removed per-test timeout flag: The
--timeoutflag is no longer forwarded to the test command since it doesn't address the documented use case (hanging in async operations).Updated documentation: Clarified that
timeout_secondsis a wall-clock budget, not a per-test timeout, and explained how it bounds hangs that bypass the test runner's timeout.New failure type: Added
ToolFailureType.timeoutto distinguish timeout failures from other errors, with appropriate recovery guidance.Tests: Added comprehensive tests verifying that:
This ensures that a single hung test cannot stall all other tool calls on the MCP server.