Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

`_onprogress` raises a protocol error for a race servers cannot avoid (progress notification arriving with the response)

未关闭 适合新手
  • 哪里不对？
#2,580 4 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@qiushui7 已经在做这个了。

开始于 2026年7月30日。

  • #2967 来自 @feniix —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
68/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
typescript
领域
api

调研方向

从 src/shared/protocol.ts 开始阅读 _onresponse 和 _onprogress，然后使用 callTool 示例以及相邻的进度和响应消息重现 race。完成的标准是：已完成请求的延迟进度通知会被丢弃，且不会触发 _onerror，同时正常的进度传递保持不变；考虑是否需要记录终止通知的行为。

由索引模型根据 Issue 内容生成。

描述

bug P2 ready for work v1 v2
Summary

When a request completes, Protocol._onresponse deletes that request's progress handler. Any progress notification for the token that is processed afterwards falls into _onprogress, finds no handler, and is reported through _onerror:

Received a progress notification for an unknown token: {...}

Discarding the notification is reasonable — once the request is done, progress for it is moot. Raising a protocol error for it is not, because a server has no way to avoid producing that condition.

Why a server cannot avoid it

A server that reports progress for a batch operation naturally emits a terminal progress === total notification just before returning the result. Those two writes are adjacent by construction. Whether the client processes the notification before or after the response is a timing race the server does not control — and on a loaded machine it loses.

Concretely, in src/shared/protocol.ts:

// _onresponse
if (!isTaskResponse) {
  this._progressHandlers.delete(messageId);
}

// _onprogress
const handler = this._progressHandlers.get(messageId);
if (!handler) {
  this._onerror(new Error(`Received a progress notification for an unknown token: ...`));
  return;
}

So any server emitting a terminal progress notification will intermittently cause onerror to fire in every client. For hosts that log or surface protocol errors, a well-behaved server ends up manufacturing spurious error noise on a successful operation.

Attempting to fix it server-side does not work. Awaiting the notification sends before returning the result orders the writes correctly, but cannot prevent the client from tearing down its handler before it dispatches them.

Reproduction

Server emits N progress notifications then the result, with no artificial spacing between them. Client:

const progress: unknown[] = [];
const errors: string[] = [];
client.onerror = (e) => errors.push(e.message);

await client.callTool({ name: "export", arguments: { /* 3 items */ } },
  CallToolResultSchema, { onprogress: (p) => progress.push(p) });

Observed (server sent 4 notifications, all before the result):

received=1
errors=[
  'Received a progress notification for an unknown token: {"method":"notifications/progress","params":{"progress":1,"total":3,...,"progressToken":1}}',
  '...{"progress":2,...}',
  '...{"progress":3,...}'
]

One delivered, three discarded with an error each. With ~100ms spacing between notifications the same code delivers all four — i.e. it is purely a timing race, not a protocol violation by either side.

Observed with @modelcontextprotocol/sdk 1.29.0 over stdio.

Suggested change

Treat "progress notification for a request that has just completed" as an expected, benign race rather than an error:

  • don't route it to _onerror; ignore it silently, or log at debug level; or
  • keep a short grace period after response for recently-completed tokens and drop matching notifications quietly.

Either removes the false error without changing the (sensible) decision not to deliver late progress.

Secondary question

Is there any supported way for a server to deliver a terminal progress notification reliably? If not, that is worth stating in the spec/docs, so server authors know the final progress === total frame is inherently best-effort and clients know not to build completion UI on it. Right now it looks reliable, and fails only under load.

主要语言
TypeScript
星标
13.6k
派生
2.3k
平均合并
1 天 5 小时
30 天内合并 PR
52

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/typescript-sdk 的其他 Issue

查看 modelcontextprotocol/typescript-sdk 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。