SEP-XXXX: Tasks are (not) Progress#11
SEP-XXXX: Tasks are (not) Progress#11LucaButBoring wants to merge 5 commits intomodelcontextprotocol:mainfrom
Conversation
|
Following today's discussion, progress will no longer be removed in this proposal (or at least, we're deferring that topic). The proposal has been mostly rewritten, except for the Rationale section (will be ready by Friday). I decided to also backport the new requirements around |
|
Updated Rationale as well. |
LucaButBoring
changed the title
|
|
||
| However, in Streamable HTTP, combining these features creates ambiguous behavioral tradeoffs regarding the `input_required` status, which is not specified to be used with notifications in the first place - only with requests. If a server wishes to send progress notifications to a client, it must decide if those notifications should be sent on the GET stream used for background messages, side-channeled on the SSE stream during the `tasks/get` operation, or side-channeled during the `tasks/result` operation. In the case of the background stream and `tasks/result`, this forces the server to keep an active handler for the full duration of the task lifetime, and in the case of `tasks/get`, the server must be able to dequeue server-to-client events in a consistent order from any invocation of the `tasks/get` method. | ||
|
|
||
| To sidestep this complexity, this proposal introduces progress fields directly into tasks, allowing servers to simply always have a mechanism for communicating progress changes without navigating stream selection at all. |
There was a problem hiding this comment.
To be clear: we are proposing that there will be no way to get real-time progress notifications for tasks? (or any other streamed information that we may -- and almost certainly will -- want to add in future)
There was a problem hiding this comment.
@pja-ant Not necessarily, just that this will be a better option for progress specifically. Other notifications still exist and have these problems, but progress is one we feel is important enough to create an easier alternative for.
| As with progress notifications, `progress` **MUST** be monotonically increasing, and `progressTotal` will remain optional as the total amount of work may be unknown. Both values may be floating-point numbers. *In addition* to these properties, we will define the following new behavior for `progressTotal` (and `total` in the progress specification), as it was previously underspecified: | ||
|
|
||
| 1. `progressTotal` **MAY** be omitted, but if it is provided it **MUST** be greater than or equal to `progress`. | ||
| 2. `progressTotal` **MAY** change between requests, but it **MUST** be monotonically increasing (similar to `progress`). A changing total may represent new work being discovered, for example. |
There was a problem hiding this comment.
nit: but I don't think we need the increasing constraint. It may be rare, but it may be possible that some work becomes no-longer required during operation (e.g. the task is to work through a todo-list and an item gets cancelled mid-task).
There was a problem hiding this comment.
That creates some odd edge cases where progress and progressTotal are no longer consistent with each other, I think? There is already a requirement that progress is monotonically increasing, meaning that without this requirement, there's an edge that looks like this:
- A tool begins with 5 work items. The first 3 are essential; the last 2 are not.
- The first 4 items complete, putting progress at 4/5.
- The last two items are no longer necessary and are both dropped, putting progress at 4/3.
2 participants
This is a draft proposal adding
progressandprogressTotalfields to tasks, following discussions with @CaitieM20 and @markdroth.Motivation and Context
This proposal allows developers using tasks to communicate progress without needing to leverage progress notifications explicitly.
How Has This Been Tested?
TBD
Breaking Changes
None.
Types of changes
Checklist
Additional context