fix(den): attribute our own MCP lifecycle deadline to OpenWork - #3088
Merged
Conversation
A capability that outran the bounded deadline was reported as an unrecognized provider error, telling the member to look up a JSON-RPC code with a provider that never sent one. The abort reason was a plain Error, and the SDK only rethrows an McpError untouched -- everything else becomes String(reason) on a RequestTimeout, so the deadline reached diagnostics indistinguishable from a provider-declared -32001. Abort with a marked McpError instead and check that marker before any JSON-RPC code is read as the provider's. Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
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.
What
A capability that outran OpenWork's bounded deadline was reported to the member as an unrecognized provider error, instructing them to "look up the provider-declared JSON-RPC error code with the provider" — for a timeout the provider never declared:
That quoted "provider" message is our own abort text from
packages/enterprise-mcp-client.Why it happened
The lifecycle timer aborted with a plain
Error. The MCP SDK rethrows an abort reason untouched only when it is already anMcpError; anything else is collapsed intoString(reason)on a freshRequestTimeout(shared/protocol.js):So all structure was lost. Den's classifier saw code
-32001with nodata.timeout, and its only remaining branch for that code was "provider-declared".Change
EnterpriseMcpLifecycleDeadlineError(anMcpErrorsubclass) carrying a marker ondata, so the SDK passes it through intact.classifyErrorbefore any JSON-RPC code is read as the provider's, classifying it as the existing retryableMCP_LIFECYCLE_DEADLINE.Detection is structural, not message-based — Den labels provider messages untrusted, so trust decisions must not depend on their text.
Tests
npx tsx --test test/*.test.tsinpackages/enterprise-mcp-client— 59 pass, 0 fail (4 new: the abort is anMcpError, the marker survives the SDK round trip, detection through a wrapped cause chain, and a provider's ownRequestTimeoutis not claimed as ours).bun test test/external-mcp-diagnostics.test.tsinee/apps/den-api— 61 pass, 19 fail, versus 59 pass, 19 fail onorigin/devat baseline (verified by stashing). The same 19 fail before and after; my 2 new tests pass. Typecheck clean for both touched packages.No fraimz: this is hosted Den API classification with no desktop UI path of its own, and the 31s failure needs a provider that stalls past the deadline. The unit tests assert the exact member-visible message and that
operatorActionno longer mentions a JSON-RPC code. Reviewer repro: the two new cases inexternal-mcp-diagnostics.test.ts.Made with Cursor