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

[v1.x] Protocol.request keeps its abort listener after the request resolved, so a later abort sends notifications/cancelled for an answered request (1.30.0)

オープン 初心者向け
  • 何か問題がありますか？
#3,090 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@suryakant-source がすでに取り組んでいます。

2026年10月24日 から。

  • #3091 @suryakant-source による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
76/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
node.js, typescript
領域
api, backend

調査の方向性

ブランチ v1.x の src/shared/protocol.ts を読み、main の packages/core-internal/src/shared/protocol.ts と中断リスナーの処理を比較してください。提供されたインメモリのクライアント／サーバーの例で再現し、リクエストの解決後にシグナルを中断しても notifications/cancelled 通知が送信されないことを確認してください。

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

説明

v1
Summary

Protocol.request() registers its 'abort' listener on options.signal and never removes it. Once the request has resolved, the listener is still attached, so a caller that later aborts the controller (because the operation it guarded is over and it is releasing resources) makes cancel() run and send a notifications/cancelled for a request that was already answered. The server then receives a cancellation for a finished request, and over Streamable HTTP that is one extra POST per call.

Seen on @modelcontextprotocol/sdk 1.30.0 (Node 24). The v1.x branch (3b73021) still has the same code in src/shared/protocol.ts:

options?.signal?.addEventListener('abort', () => {
    cancel(options?.signal?.reason);
});

cancel() deletes the response handler and clears the timeout, which are no-ops after resolution, but the this._transport?.send({ method: 'notifications/cancelled', ... }) call still goes out. The reject(error) is a no-op on the settled promise, so the caller sees nothing. The v2 line (packages/core-internal/src/shared/protocol.ts on main) already guards this with responseReceived, registers the listener with { once: true } and removes it once the response arrives; v1.x does not.

Reproduction
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { InMemoryTransport } from "@modelcontextprotocol/sdk/inMemory.js";
import { CallToolRequestSchema, CancelledNotificationSchema } from "@modelcontextprotocol/sdk/types.js";

const server = new Server({ name: "repro-server", version: "1.0.0" }, { capabilities: { tools: {} } });
server.setRequestHandler(CallToolRequestSchema, async () => ({ content: [{ type: "text", text: "done" }] }));
server.setNotificationHandler(CancelledNotificationSchema, async (n) => console.log("server received:", JSON.stringify(n.params)));

const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();
await server.connect(serverTransport);
const client = new Client({ name: "repro-client", version: "1.0.0" });
await client.connect(clientTransport);

const controller = new AbortController();
const result = await client.callTool({ name: "echo", arguments: {} }, undefined, { signal: controller.signal });
console.log("resolved:", JSON.stringify(result));

// The caller is done with the request and releases its controller.
controller.abort("caller released the controller");
await new Promise((resolve) => setTimeout(resolve, 50));

Output with 1.30.0:

resolved: {"content":[{"type":"text","text":"done"}]}
server received: {"requestId":1,"reason":"caller released the controller"}

Expected: nothing after resolved:. A request that has resolved has nothing left to cancel; the abort listener should be removed (or cancel() should return) once the response handler has run, as main already does.

How we hit it

Our runtime hands each HTTP request's AbortController to callTool and aborts it on the Node response's 'close' event, which fires for a normally finished response as well. Every completed tool call was therefore followed by a notifications/cancelled that travelled through our proxy and authorization path like a real call. We have stopped aborting after a finished response on our side; this report is for the listener that stays attached.

主要言語
TypeScript
スター
13.7k
フォーク
2.3k
平均マージ
1日 6時間
マージ済み PR（30日）
53

環境構築

はじめの一歩

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

modelcontextprotocol/typescript-sdk のほかの issue

modelcontextprotocol/typescript-sdk の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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