[v2] e2e `protocol:timeout:max-total` is flaky over SSE: fake timers advance before the request reaches the server
維護者通常 1 天內回覆
評估
- 難度
- 2/5
- 預估耗時
- 1-3 小時
- 新手友好度
- 72/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- typescript
- 領域
- testing-qa
研究方向
從 test/e2e/scenarios/protocol.test.ts 中 protocol:timeout:max-total 的 SSE 變體開始，並將它們的虛擬計時器步驟與 timeout:reset-on-progress 測試的 vi.waitFor 模式進行比較。執行 issue 中的重現命令，包括重複執行，以確認間歇性失敗。完成條件是測試能可靠地到達伺服器的進度事件，且 SSE 像其他傳輸方式一樣回報 Maximum total timeout exceeded。
由索引模型根據 Issue 內容生成。
描述
What happened?
On macOS, the two SSE variants of protocol:timeout:max-total in test/e2e/scenarios/protocol.test.ts fail intermittently on a clean clone of main. The other transports always pass, and CI on main is green.
AssertionError: expected 0 to be greater than or equal to 3
❯ scenarios/protocol.test.ts:713:30
followed by an unhandled SdkError: Request timed out.
The failure rate moves around. On Oct 14 it failed in the full suite and in 3 of 3 isolated runs. On Oct 16, -t "timeout:basic|timeout:max-total" failed 3 of 6 times, while the max-total test on its own passed 6 of 6.
What I think is happening: the test switches to fake timers, starts the call, and immediately advances the clock in 200ms steps. Over SSE, the tools/call request is a real HTTP POST, and the fake clock doesn't wait for it. When the POST is slow to land, the clock is already past the 500ms per-request timeout, so the call rejects with Request timed out before the server sends any progress. In those runs the test never reaches maxTotalTimeout at all.
To check, I added temporary logging of server-sent progress, client-received progress, and each clock step. In failing runs, the server's first progress shows up only after the clock reaches 600ms, by which point the call has already been rejected. Then I added 10ms of real time (a setTimeout captured before useFakeTimers) after each advanceTimersByTimeAsync. With that, all 12 variants passed on 3 of 3 runs, and SSE rejects with Maximum total timeout exceeded after 4 progress ticks, the same as the other transports.
The sleep only confirms the cause; it isn't a fix. protocol:timeout:reset-on-progress already avoids this race by awaiting vi.waitFor(() => expect(received.length).toBeGreaterThanOrEqual(i)) after each step, and max-total has no equivalent. Waiting until the server has received the call before advancing the clock should fix it. One wrinkle: vi.waitFor advances fake timers while it polls, so the wait needs to sit where it can't eat into the timeout budget under test.
Happy to open a test-only PR if that approach sounds right.
What did you expect?
The test passes regardless of machine speed, and actually exercises maxTotalTimeout over SSE.
Code to reproduce
cd test/e2e
pnpm vitest run scenarios/protocol.test.ts -t "timeout:basic|timeout:max-total"
# intermittent, so run it several times
SDK version
main @ 9bc40e90 (macOS / Darwin 27, Node 24.16.0, pnpm 10.26.1)
Area
Transports
- 主要語言
- TypeScript
- 星號
- 13.7k
- 分支
- 2.3k
- 平均合併
- 1 天 2 小時
- 30 天內合併 PR
- 61
環境準備
- 沒有 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 於 1 天前認領。 未關閉v1 v2
難度 2/5 1-3 小時 新手友好度 78/100
modelcontextprotocol/typescript-sdk#3111 · 3 則留言 ·
維護者通常 1 天內回覆
-
server: registeredResource.update and registeredResourceTemplate.update desync title and metadata.title when updating metadata alone可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉v1 v2
難度 2/5 1-3 小時 新手友好度 76/100
modelcontextprotocol/typescript-sdk#3103 · 2 則留言 ·
維護者通常 1 天內回覆
-
[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)可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉v1
難度 2/5 1-3 小時 新手友好度 76/100
modelcontextprotocol/typescript-sdk#3090 · 2 則留言 ·
維護者通常 1 天內回覆
-
[v1.x] Backport #2654: `notifications/cancelled` with `requestId: 0` is ignored, so the first server→client request cannot be cancelled (still in 1.32.1)可能已有人在做 @CloudCorpRecords 於 11 天前認領。 未關閉v1
難度 2/5 1-3 小時 新手友好度 77/100
modelcontextprotocol/typescript-sdk#3043 · 2 則留言 ·
維護者通常 1 天內回覆
-
v1 v2
難度 2/5 1-3 小時 新手友好度 72/100
modelcontextprotocol/typescript-sdk#2946 · 4 則留言 ·
維護者通常 1 天內回覆
查看 modelcontextprotocol/typescript-sdk 的全部 Issue
相似的 Issue
-
難度 1/5 1 小時以內 新手友好度 78/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
liberation-data/drivine#428 · 1 則留言 ·
維護者通常 1 天內回覆
-
GitLab: a merge request closed without merging keeps the Git toolbar on View MR instead of Create MR未關閉
難度 2/5 1-3 小時 新手友好度 82/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
code-yeongyu/oh-my-openagent#11731 ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 78/100