fix(connect): extend external MCP tool timeout - #2750
Merged
reachjalil merged 1 commit intoJul 14, 2026
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
Contributor
|
@reachjalil is attempting to deploy a commit to the Different AI Team on Vercel. A member of the Team first needs to authorize it. |
benjaminshafii
added a commit
that referenced
this pull request
Jul 25, 2026
…t path (#3122) An external MCP capability got 30s for the whole session -- connect, OAuth refresh, initialize and tools/call shared one budget -- and execute_capability spent that budget twice, once for schema-digest discovery and once for the call. Slow providers died at ~31s. The 120s/150s tool budget from #2750 was never reached. #2810 deleted the legacy runtime, so callExternalMcpTool resolves to the enterprise client, and the adapter's tool-call path forwarded no lifecycle deadline -- unlike listExternalMcpTools beside it -- leaving the package's 30s default in charge. A Math.min(operationTimeoutMs, ...) clamp meant injecting the longer deadline would have been clipped back to 30s anyway. The only test asserting 120s exercised the bypassed file. Make an injected lifecycle deadline authoritative in both directions and demote operationTimeoutMs to the fallback default. Forward the deadline on the tool-call path, and share one deadline between discovery and the call so the handshake and the budget are paid once. Split the per-request timeout from the absolute bound and stop cancelling a provider that is still reporting progress, matching the calling harness instead of being stricter than it; the SDK only attaches a progressToken when an onprogress handler is present, so the flag alone was inert.
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
1 participant
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
Root cause
Long-running provider tools, including ServiceNow incident summarization, could exceed OpenWork's 30-second Den-side request limit even after authentication and MCP initialization succeeded.
Impact
External MCP tools can complete longer operations without weakening the existing connection and payload safety limits.
Validation
pnpm exec bun test ee/apps/den-api/test/external-mcp-diagnostics.test.ts -t "allows tool execution to use a longer bounded request timeout"Full Den API and end-to-end provider suites were not run.