Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#24 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api, backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
51
フォーク
10
平均マージ
5日 4時間
マージ済み PR（30日）
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/ext-tasks のほかの issue

modelcontextprotocol/ext-tasks の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。