Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#24 2 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
api, backend-api-design

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

question
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.

Linguagem predominante
TypeScript
Estrelas
52
Forks
12
Merge médio
4d 23h
PRs com merge (30d)
4

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de modelcontextprotocol/ext-tasks

Todas as issues de modelcontextprotocol/ext-tasks

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.