Keep the 1.x handler registration forms as deprecated overloads - #769
Merged
Conversation
Consumers on 1.x wrote setRequestHandler(Schema, handler) and
setNotificationHandler(Schema, handler) with a whole-message Zod schema.
SDK 2.0 keys handlers by method name, so App and AppBridge now accept
that form as a third, deprecated overload: a small helper detects the
schema, extracts the method literal, forwards to the 2.x
(method, { params }, handler) form, and hands the legacy handler the
reassembled { method, params } message plus a 1.x-shaped extra
(signal, requestId, sessionId, _meta). A one-time console warning
points at the new form. The double-registration guard applies to both
forms.
The AppRequest, AppNotification and AppResult unions that 1.x fed to
the SDK's Protocol generics come back as deprecated type aliases, since
they leaked through the root entry and cost nothing to keep.
Both go away in 3.0.
Contributor
PreviewPreview deployments for this PR have been cleaned up. |
@modelcontextprotocol/ext-apps
@modelcontextprotocol/server-basic-preact
@modelcontextprotocol/server-basic-react
@modelcontextprotocol/server-basic-solid
@modelcontextprotocol/server-basic-svelte
@modelcontextprotocol/server-basic-vanillajs
@modelcontextprotocol/server-basic-vue
@modelcontextprotocol/server-budget-allocator
@modelcontextprotocol/server-cohort-heatmap
@modelcontextprotocol/server-customer-segmentation
@modelcontextprotocol/server-debug
@modelcontextprotocol/server-lazy-auth
@modelcontextprotocol/server-map
@modelcontextprotocol/server-pdf
@modelcontextprotocol/server-scenario-modeler
@modelcontextprotocol/server-shadertoy
@modelcontextprotocol/server-sheet-music
@modelcontextprotocol/server-system-monitor
@modelcontextprotocol/server-threejs
@modelcontextprotocol/server-transcript
@modelcontextprotocol/server-video-resource
@modelcontextprotocol/server-wiki-explorer
commit: |
They appear in App's public setRequestHandler / setNotificationHandler signatures, so TypeDoc's link validation needs them reachable from the entry point.
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.
Follow-up to #768. Two of the breaks listed in the migration guide were cheap to keep as deprecated compatibility, so this restores them for the 2.x line:
setRequestHandler(Schema, handler)/setNotificationHandler(Schema, handler)still work onAppandAppBridgeas a third,@deprecatedoverload next to the two 2.x forms. A small helper (src/legacy-handlers.ts) detects the whole-message Zod schema, extracts themethodliteral, and forwards to the 2.x(method, { params }, handler)form; the legacy handler gets the reassembled{ method, params }message and, for requests, a 1.x-shapedextra(signal,requestId,sessionId,_meta,sendRequest,sendNotification,authInfo) built from the 2.xBaseContext. A one-timeconsole.warnpoints at the new form. The double-registration guard from SDK 2.0 fixups: lockfile, peers, handler guards, docs, wire-compat tests #768 applies to both forms.AppRequest,AppNotification,AppResultcome back as deprecated type aliases. 1.x fed them to the SDK'sProtocolgenerics; nothing in 2.x consumes them, but they leaked through the root entry and are free to keep.Both are marked for removal in 3.0, and the migration guide now says "deprecated" rather than "gone" for these.
Tests:
src/legacy-handlers.test.tscovers a custom request and notification through the old form on each class (message shape,extrashape, one-time warning) and that the guard still throws foron*-owned and event-mapped methods. A throwaway consumer file confirms the 1.x form, the 2.x spec form and the 2.x custom form all type-check side by side with the expectedextra/ctxtypes.+173/−28 in
src/, most of it the union aliases.