Stalled tasks

[symdeb]

Assume an client loses control over the outstanding tasks running on MCP server.

1. There is no tasks/list call. How would a stale tasks that may still run on the MCP server be known by the client ?
2. When should an MCP server stop a task ?

[AndresSaa]

My reading of the current draft is:

1. There is deliberately no recovery by enumeration. Clients SHOULD persist task IDs so polling can resume after a crash or restart. If a client also loses those IDs, the extension provides no way to rediscover the tasks. The security considerations give the absence of tasks/list as the reason a server cannot inadvertently leak the existence of one caller's tasks to another.
2. ttlMs defines a usability and retention backstop, but I do not think it fully answers when the underlying work should stop. It is measured from createdAt; after createdAt + ttlMs, a client MAY consider the task unusable, and the server MAY mark it failed and subsequently delete it. However, the cancellation section says that stopping work is cooperative and that the server is not obligated to stop it even after tasks/cancel.

So, if "stop a task" means stop retaining or exposing its state, a finite TTL provides the boundary. If it means terminate the underlying computation, the current draft appears to leave that server-defined. Is that distinction intentional, or is TTL expiry expected to trigger cancellation of the underlying work?

[LucaButBoring]

That distinction is indeed intentional, because the storage (and therefore the operational burden) of a task rests with the server, rather than the client. The spec as currently-written is intended to allow the server a significant degree of freedom in how it manages tasks to accommodate eventually-consistent dependencies.