Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 30 additions & 3 deletions docs/specification/draft/basic/utilities/tasks.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,12 @@ Task-augmented requests follow a two-phase response pattern that differs from no
- **Normal requests**: The server processes the request and returns the actual operation result directly.
- **Task-augmented requests**: The server accepts the request and immediately returns a `CreateTaskResult` containing task data. The actual operation result becomes available later through `tasks/result` after the task completes.

To create a task, requestors send a request with the `task` field included in the request params. Requestors **MAY** include a `ttl` value indicating the desired task lifetime duration (in milliseconds) since its creation.
To create a task, requestors send a request with the `task` field included in the request params. Requestors **MAY** include some additional information:

- `ttl` value indicating the desired task lifetime duration (in milliseconds) since its creation
- `extensions` object providing arbitrary extension metadata for the task, used to control how task will be handled.
- `context` object providing context metadata for the task, such as identity information.
- `bizContext` object providing business context metadata for the task, if the server received this, it should respond the same `bizContext` in the task-related responses and notifications.
Comment on lines +133 to +135

@LucaButBoring LucaButBoring Mar 13, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like all three of these additional fields contain arbitrary data? Are there any reasons why these wouldn't be regular request parameters or defined by an actual protocol extension? Thinking on these more, they only appear to make sense if you control both the client and server implementations, at which point it's acceptable to do whatever additional logic you like (but you might want to codify that in an extension specification).

@LucaButBoring LucaButBoring Mar 13, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without a specific use case it's hard to judge how this will be used, but extrapolating from the PR description, if what you want is a way to pass a webhook callback outside the scope of the specification, an extension seems to make more sense than having spec-defined fields which the host application can't use unless it's built-to-purpose for a specific use case (there's also a new Triggers and Events Working Group which should start to be a useful discussion platform for that particular topic once they're fully set up, but setting that aside).


**Request:**

Expand All @@ -142,7 +147,18 @@ To create a task, requestors send a request with the `task` field included in th
"city": "New York"
},
"task": {
"ttl": 60000
"ttl": 60000,
"extensions": {
"priority": "high"
},
"context": {
"identity": {
"userNick": "huming"
}
},
"bizContext": {
"customerId": "12345"
}
}
}
}
Expand All @@ -161,7 +177,18 @@ To create a task, requestors send a request with the `task` field included in th
"statusMessage": "The operation is now in progress.",
"createdAt": "2025-11-25T10:30:00Z",
"ttl": 60000,
"pollInterval": 5000
"pollInterval": 5000,
"extensions": {
"priority": "high"
},
"context": {
"identity": {
"userNick": "huming"
}
},
"bizContext": {
"customerId": "12345"
}
}
}
}
Expand Down