add diagrams, schemas, http headers, and specify Gettask Behavior.#1
Conversation
| /** | ||
| * Optional field containing the Result of a Task. Present only when task status is `completed`. | ||
| */ | ||
| result?: JSONObject; | ||
|
|
||
| /** | ||
| * Optional field containing the error that caused the task to fail. Present only when task status is `failed`. | ||
| */ | ||
| error?: JSONObject; |
There was a problem hiding this comment.
These get inlined into Task, not GetTaskResult (that is, these changes affect every request/notification that uses the Task type).
There was a problem hiding this comment.
Does that make sense though? For example CreateTaskResult is now
interface CreateTaskResult extends Result
{
task: Task
} So with having these in-lined with task you could return an error or result which doesn't really make sense.
There was a problem hiding this comment.
Yeah, after further discussion, I think we should use a separate type instead of Task here and in tasks/list - naming TBD
|
|
||
| For backwards compatibility ResultType is inferred to be `complete`. Therefore all calls which return a `Task` (i.e.`task/get`, `task/cancel`) calls must set `task` as the ResultType moving forward. | ||
|
|
||
| ### Example Task Flow |
There was a problem hiding this comment.
nit: might want to specify the result types (that is, to clarify tools/call returns CreateTaskResult)
| #### Failed | ||
| When a task is in the `failed` state, a call to `tasks/get` should return an error in the `result` field indicating the reason for the failure. | ||
|
|
||
| TBD On what this looks like. |
There was a problem hiding this comment.
At least right now this would be a JSONRPCError, though the question stands of how we want to handle failed tool calls
| [SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243) introduces standard headers in the Streamable HTTP Transport to facilitate more efficient routing. Routing on `TaskId`is also desirable since there is often state associated with a specific Task that needs to be consistently routed to the same server instance. | ||
|
|
||
| For Tasks the following Headers MUST be set by the client when making requests over the Streamable HTTP Transport: | ||
| - `Mcp-Method`: `tasks/get`, `tasks/cancel` |
There was a problem hiding this comment.
Should we also mention tasks/list here? It wouldn't have an Mcp-Name but the consistency would be useful
|
Merging - will handle the followups in a batch early tomorrow |
LucaButBoring
merged commit 614ec39
into
LucaButBoring:feat/tasks-stabilization
2 participants
Updating SEP doc.
Adding
Still have todos around error handling flow