[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)
维护者通常 1 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 76/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- node.js, typescript
调研方向
阅读分支 v1.x 上的 src/shared/protocol.ts，并将其对 abort 监听器的处理方式与 main 上的 packages/core-internal/src/shared/protocol.ts 进行比较。使用提供的内存客户端/服务器示例重现问题，然后验证请求完成后中止 signal 不会发送 notifications/cancelled 通知。
由索引模型根据 Issue 内容生成。
描述
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 天 2 小时
- 30 天内合并 PR
- 60
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/typescript-sdk 的其他 Issue
-
The `maxToolInputElements` refusal lacks the `Input validation error:` prefix that the schema refusal carries可能已有人在做 @barry166 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
modelcontextprotocol/typescript-sdk#3111 · 1 条评论 ·
维护者通常 1 天内回复
-
v2
难度 2/5 1-3 小时 新手友好度 71/100
modelcontextprotocol/typescript-sdk#3109 ·
维护者通常 1 天内回复
-
server: registeredResource.update and registeredResourceTemplate.update desync title and metadata.title when updating metadata alone可能已有人在做 @FelixFangX 于 1 天前认领。 未关闭v1 v2
难度 2/5 1-3 小时 新手友好度 76/100
modelcontextprotocol/typescript-sdk#3103 · 2 条评论 ·
维护者通常 1 天内回复
-
[v2] server/client 2.4.0 inline fast-uri 3.1.8; four advisories published after release are fixed in 3.1.9可能已有人在做 @claude 于 1 天前认领。 未关闭v2
难度 2/5 1-3 小时 新手友好度 72/100
modelcontextprotocol/typescript-sdk#3101 ·
维护者通常 1 天内回复
-
[v2] e2e `protocol:timeout:max-total` is flaky over SSE: fake timers advance before the request reaches the server可能已有人在做 @Singmin 于 9 天前认领。 未关闭v1 v2
难度 2/5 1-3 小时 新手友好度 72/100
modelcontextprotocol/typescript-sdk#3045 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/typescript-sdk 的全部 Issue
相似的 Issue
-
comp/desktop desktop/shell os/windows P3 tool/file type/bug
难度 2/5 1-3 小时 新手友好度 76/100
NousResearch/hermes-agent#145928 ·
维护者通常 1 天内回复
-
compiler-dom: stringifyStatic renders :disabled="0" as a present attribute可能已有人在做 @DaZuiZui 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 74/100
-
integration:coding-agents
难度 1/5 1 小时以内 新手友好度 83/100
vectorize-io/hindsight#6151 ·
维护者通常 1 天内回复
-
DogFooding
难度 1/5 1 小时以内 新手友好度 88/100
OpenAEV-Platform/openaev#8768 ·
维护者通常 1 天内回复