You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(server)!: remove getTask/getTaskResult from ToolTaskHandler
These handlers were defined on the ToolTaskHandler interface but never
invoked by the SDK. Three code paths bypassed them and called TaskStore
directly:
- TaskManager.handleGetTask
- TaskManager.handleGetTaskPayload
- McpServer.handleAutomaticTaskPolling
Every test and example implementation was pure boilerplate delegation
to ctx.task.store. Rather than wire them up (which would require
in-memory taskId→tool mapping that doesn't survive restarts or
multi-instance deployments), this removes them.
The TaskStore interface remains the pluggable extension point for
custom task retrieval.
Also adds an isToolTaskHandler type guard and uses it in place of
inline 'createTask' in checks.
BREAKING CHANGE: ToolTaskHandler.getTask and ToolTaskHandler.getTaskResult
have been removed. Delete these methods from your registerToolTask
handlers. If you need custom task retrieval, implement a custom
TaskStore.
Closes#1332
Co-authored-by: Luca Chang <lucalc@amazon.com>
Remove `getTask` and `getTaskResult` from `ToolTaskHandler`
6
+
7
+
**Breaking changes (experimental API):**
8
+
9
+
-`ToolTaskHandler` now only defines `createTask`. The `getTask` and `getTaskResult` handlers have been removed.
10
+
-`TaskRequestHandler` type has been removed.
11
+
12
+
These handlers were never invoked by the SDK — `tasks/get` and `tasks/result` requests were always served directly from the configured `TaskStore`, bypassing the user's handlers. Rather than wire them up (which would require in-memory taskId→tool mapping that doesn't survive restarts), we've removed them.
13
+
14
+
**Migration:** Delete your `getTask` and `getTaskResult` implementations. If you need to customize task retrieval, implement a custom `TaskStore` instead — it's the pluggable interface that `tasks/get` and `tasks/result` consult.
### `ToolTaskHandler.getTask` and `getTaskResult` removed (experimental)
482
+
483
+
The `getTask` and `getTaskResult` methods have been removed from the experimental `ToolTaskHandler` interface. These handlers were never invoked by the SDK — `tasks/get` and `tasks/result` requests are served directly from the configured `TaskStore`.
Copy file name to clipboardExpand all lines: packages/server/src/experimental/tasks/mcpServer.ts
+4-9Lines changed: 4 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -45,8 +45,9 @@ export class ExperimentalMcpServerTasks {
45
45
* Registers a task-based tool with a config object and handler.
46
46
*
47
47
* Task-based tools support long-running operations that can be polled for status
48
-
* and results. The handler must implement {@linkcode ToolTaskHandler.createTask | createTask}, {@linkcode ToolTaskHandler.getTask | getTask}, and {@linkcode ToolTaskHandler.getTaskResult | getTaskResult}
49
-
* methods.
48
+
* and results. The handler implements {@linkcode ToolTaskHandler.createTask | createTask}
49
+
* to start the task; subsequent `tasks/get` and `tasks/result` requests are served
50
+
* from the configured {@linkcode TaskStore}.
50
51
*
51
52
* @example
52
53
* ```typescript
@@ -59,19 +60,13 @@ export class ExperimentalMcpServerTasks {
0 commit comments