fix(runtime): stop the dynamic-tool-result backstop from undercutting long tool executions - #6848
Merged
Hmbown merged 1 commit intoOct 5, 2026
Conversation
… long tool executions The headless Runtime API raises the MCP `tools/call` budget to a 1800s default (`McpTimeouts::default()` execute_timeout) so legitimate long executions — builds, test suites, remote jobs — are not answered with "timed out" while the tool is still running. The dynamic-result backstop in runtime_threads, however, still capped the wait for the client-executed result at 300s: a healthy MCP call in the 300s-1800s window got its pending result dropped and a ToolError::Timeout handed to the model even though the execution was allowed to continue. Align the backstop with the 1800s `tools/call` budget so the two clocks no longer disagree, and pin the pairing with a unit test. The wait still ends early on turn interrupt or runtime shutdown, so the raised cap only governs the case where the client never answers. Signed-off-by: asto <asto18089@126.com>
github-actions
Bot
added
the
contribution-gate
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The headless Runtime API's MCP
tools/callbudget defaults to 1800s (McpTimeouts::default()), but the dynamic tool-result backstop still capped the wait for a client-executed result at 300s: a healthy call in the 300–1800s window had its result delivery dropped withToolError::Timeoutwhile the execution itself was still allowed to run.Align the backstop with the 1800s budget and pin the pairing with a unit test. The wait still ends early on turn interrupt or runtime shutdown (
settle_dynamic_tools_for_terminal_turn), so the cap only governs a client that never answers.Testing
cargo test -p codewhale-tui --lib dynamic_tool_result— new pin asserts the backstop equalsMcpTimeouts::default().execute_timeoutand 1800s; the existing behavior test (dynamic_tool_timeout_clears_snapshot_and_emits_once) covers the firing path via the test seamcargo clippy -p codewhale-tui --all-targets --all-features --lockedAdapted from the Pinvou fork's timeout audit (Pinvou/CodeWhale
d349f2537), on top of the budgets introduced by #6741.Checklist
CHANGELOG.mdchanges