Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#24 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, backend-api-design

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
51
Forks
10
Merge medio
5 d 4 h
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/ext-tasks

Todos los issues de modelcontextprotocol/ext-tasks

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.