-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[RFC] refactor: extract task orchestration from Protocol into TaskManager #1449
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: c76a53b The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
c3104d6 to
b783fcd
Compare
1cf942d to
adf1507
Compare
Extract all task-related logic from Protocol into a dedicated TaskManager class with consolidated lifecycle API and NullTaskManager (Null Object pattern). Protocol delegates to TaskManager via 4 lifecycle methods: - processInboundRequest: context extraction + function wrapping - processOutboundRequest: metadata augmentation + queue routing - processInboundResponse: side-channel handling + progress preservation - processOutboundNotification: task-related notification routing NullTaskManager provides no-op defaults, eliminating all conditional checks in Protocol.
adf1507 to
c76a53b
Compare
| return { | ||
| ...task | ||
| } as Result; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does Task not satisfy GetTaskResult already?
| // Per spec: tasks/get responses SHALL NOT include related-task metadata | ||
| // as the taskId parameter is the source of truth |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I don't think this comment is relevant here?
|
Does this affect how task tools are registered and executed as well? It doesn't look like it does, but I just wanted to verify that first - I believe this supersedes #1315, but I'm unsure if it supersedes #1332 as well or not. Looks good overall though, I have similar problems in the Java SDK (modelcontextprotocol/java-sdk#755) and will probably copy part of this approach over there. |
Extracts experimental task orchestration logic from Protocol into a dedicated TaskManager class.
Protocol.ts drops from 1,736 to 992 lines. Task handler registration, message queuing, polling, and state management now live in TaskManager.
Protocol delegates through 5 lifecycle methods (
processInboundRequest,processOutboundRequest,processInboundResponse,processOutboundNotification,onClose) and a NullTaskManager provides no-op defaults when tasks are not configured.Motivation and Context
Task logic was spread across every major Protocol method, making it hard to reason about either concern independently. Since tasks are experimental, this isolation makes Protocol easier to maintain.
Breaking Changes
ProtocolOptions.taskStore/taskMessageQueue/ etc. moved underProtocolOptions.tasks?: TaskManagerOptionsTypes of changes
Checklist