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
fix(server): make ToolTaskHandler.getTask/getTaskResult optional and actually invoke them
These handlers were defined on the interface but never invoked — three
code paths bypassed them and called TaskStore directly:
- TaskManager.handleGetTask
- TaskManager.handleGetTaskPayload
- McpServer.handleAutomaticTaskPolling
The handlers exist to support proxying external job systems (AWS Step
Functions, CI/CD pipelines) where the external system is the source of
truth for task state. But every test/example implementation was pure
boilerplate delegation to the store.
This change makes the handlers optional: when omitted, TaskStore handles
requests (zero boilerplate, previous de-facto behavior). When provided,
they're invoked for tasks/get, tasks/result, and automatic polling.
Dispatch logic is isolated in ExperimentalMcpServerTasks. Core gains a
single setTaskOverrides() method on TaskManager — no changes to public
TaskManagerOptions type. McpServer itself gains ~5 lines.
Also drops the Args parameter from TaskRequestHandler since tool input
arguments aren't available at tasks/get/tasks/result time.
BREAKING CHANGE: TaskRequestHandler signature changed from (args, ctx)
to (ctx). ToolTaskHandler.getTask and getTaskResult are now optional.
Closes#1332
Co-authored-by: Luca Chang <lucalc@amazon.com>
Make `ToolTaskHandler.getTask`/`getTaskResult` optional and actually invoke them
7
+
8
+
**Bug fix:**`getTask` and `getTaskResult` handlers registered via `registerToolTask` were never invoked — `tasks/get` and `tasks/result` requests always hit `TaskStore` directly.
9
+
10
+
**Breaking changes (experimental API):**
11
+
12
+
-`getTask` and `getTaskResult` are now **optional** on `ToolTaskHandler`. When omitted, `TaskStore` handles the requests (previous de-facto behavior).
13
+
-`TaskRequestHandler` signature changed: handlers receive only `(ctx: TaskServerContext)`, not the tool's input arguments.
14
+
15
+
**Migration:** If your handlers just delegated to `ctx.task.store`, delete them. If you're proxying an external job system (Step Functions, CI/CD pipelines), keep them and drop the `args` parameter.
### `ToolTaskHandler.getTask` and `getTaskResult` are now optional (experimental)
482
+
483
+
`getTask` and `getTaskResult` are now optional on `ToolTaskHandler`. When omitted, `tasks/get` and `tasks/result` are served directly from the configured `TaskStore`. Their signature has also changed — they no longer receive the tool's input arguments (which aren't available at `tasks/get`/`tasks/result` time).
484
+
485
+
If your handlers just delegated to the store, delete them:
* Registers a task-based tool with a config object and handler.
46
107
*
47
108
* 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.
109
+
* and results. The handler implements {@linkcode ToolTaskHandler.createTask | createTask}
110
+
* to start the task; subsequent `tasks/get` and `tasks/result` requests are served
111
+
* from the configured {@linkcode TaskStore}.
50
112
*
51
113
* @example
52
114
* ```typescript
@@ -59,19 +121,13 @@ export class ExperimentalMcpServerTasks {
0 commit comments