Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

After a subscriptions/listen reconnect, how does a client learn about transitions it missed?

Open
  • Is something wrong?
#24 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api, backend-api-design

Research direction

Start with the cited task subscription requirements in specification/2026-07-28/tasks.md, then read the reconnection behavior in basic/patterns/subscriptions.mdx and the SSE note in changelog.mdx. Compare the server-side and client-side proposals, resolve which requirement the specification should adopt, and update the relevant task subscription text so missed transitions are handled after reconnecting.

Written by the indexing model from the issue text.

Description

Context
  • notifications/tasks carries a complete DetailedTask, "identical to what tasks/get would have returned at that moment" (specification/2026-07-28/tasks.md:477). Clients "MAY continue polling tasks/get in addition to subscribing … but need not do so" (:505).
  • In core MCP 2026-07-28, an abrupt transport drop ends a subscription (basic/patterns/subscriptions.mdx:125). The client "MAY treat [it] as a trigger to reconnect" (:157-158). On stdio it "MUST re-send subscriptions/listen", and the server "holds no subscription state across reconnections" (:160-162).
  • SSE resumability was removed on purpose in this revision (SEP-2575, changelog.mdx:28). This issue doesn't ask to bring it back. Snapshot notifications make it unnecessary for tasks, with one exception, below.
The gap

A client that follows :505 and relies on notifications alone can do this:

  1. subscriptions/listen with taskIds: [T], and the ack confirms T.
  2. The transport drops.
  3. T moves working → completed (or → input_required) while no stream exists. The notification has nowhere to go.
  4. The client reconnects and re-sends subscriptions/listen for T, and the server acks.
  5. T is terminal, so nothing further ever changes. The client never receives a notification and waits until ttlMs expires.

For input_required, the task also stalls server-side, because the client never sees inputRequests.

Proposal (either line settles it)
  • Server side: "After acknowledging a subscriptions/listen that includes taskIds, the server SHOULD send one notifications/tasks carrying the current DetailedTask for each acknowledged task ID." This is snapshot-on-subscribe, the same shape A2A's SubscribeToTask uses.
  • Client side: "A client that (re-)establishes a subscription MUST call tasks/get once for each task ID in the acknowledgement before relying on notifications alone." This needs no server change and fits the "need not poll" text as long as that text gets this qualifier.

lastUpdatedAt (tasks.md:133) already lets a client discard a stale snapshot if both a poll and a notification arrive, so either option is safe to combine with polling.

Dominant language
TypeScript
Stars
50
Forks
9
Avg merge
14d 1h
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/ext-tasks

All issues in modelcontextprotocol/ext-tasks

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.