TUI: saveResult.queue.test.ts hard-codes POSIX paths, so coverage:tui fails on Windows (not covered by #2748)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 1/5
- 预计耗时
- 1 小时以内
- 新手友好度
- 90/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- node.js, typescript
调研方向
测试文件 clients/tui/tests/saveResult.queue.test.ts 硬编码了 POSIX 路径；编辑它以从 node:path 导入 resolve 并在四个 assertions 中使用它。在 clients/tui 中运行 npx vitest run __tests__/saveResult.queue.test.ts 和 npm run check。当两个测试在 Windows 上通过且 POSIX 行为不变时完成。
由索引模型根据 Issue 内容生成。
描述
Which version line?
v2 — current (@modelcontextprotocol/inspector@latest)
Which client?
TUI
Inspector version
2.12.0 (v2/main at 72126af)
Node version
v24.14.0
Operating system (and browser, for the web client)
Windows 11 Home 10.0.26200 (PowerShell and Git Bash); npm 11.9.0 (CI pins 11.20.0)
Transport
Not applicable / never connected
MCP server under inspection
Not applicable. This is a unit-test failure; no server is involved.
Steps to reproduce
- On Windows 11 with Node 24:
git clone --branch v2/main https://github.com/modelcontextprotocol/inspector.git, thencd inspector && npm ci cd clients/tuinpx vitest run __tests__/saveResult.queue.test.ts(ornpm run coverage:tuifrom the repo root)
Expected behavior
Both tests in saveResultToFile queueing (#2571) pass on every platform, because coverage:tui is a stage of npm run local:gate.
Actual behavior
2 of 2 tests fail. saveResultToFile resolves its target with node:path resolve(cwd, path), so with cwd = "/d" the mocked writeFile receives D:\d\a.json, but the test asserts the literal "/d/a.json":
starts each write only after the previous one has settled:AssertionError: expected [ 'D:\d\a.json' ] to deeply equal [ '/d/a.json' ]a failed save does not hold up the ones queued after it:AssertionError: expected [] to have a length of 1 but got +0. This one is a consequence, not a second bug: the first test throws before it settles its mocked write, the module-scopesaveQueueinsrc/utils/saveResult.tsstays blocked behind it, andwritesis empty in the second test.
Full npm run coverage:tui on Windows: 1 failed file, 2 failed tests of 639. #2748 lists test:scripts, coverage:web and coverage:mcpdo as the Windows failures; this stage is not in it, and the gate chain aborts before reaching it.
Logs, errors, or screenshots
AssertionError: expected [ 'D:\d\a.json' ] to deeply equal [ '/d/a.json' ]
AssertionError: expected [] to have a length of 1 but got +0
Already prototyped a fix?
Prompt (reconstructed: the change was made interactively with Claude Code on my clone, not from one stored prompt; this prompt reproduces it):
In clients/tui/tests/saveResult.queue.test.ts the expected paths are POSIX literals ("/d/a.json", "/d/b.json", "/d/x.json", "/d/y.json") but saveResultToFile in clients/tui/src/utils/saveResult.ts builds its target with node:path resolve(cwd, path), so on Windows the mocked writeFile receives "D:\d\a.json" and both tests fail. Change only the test: import { resolve } from "node:path", add const inD = (name: string) => resolve("/d", name), and use inD("a.json") etc. in the four assertions. Do not change the source, do not skip on win32, do not mock node:path. Then run
npx vitest run __tests__/saveResult.queue.test.tsandnpm run checkin clients/tui, andnpm run coverage:tuifrom the root.
Verified: before, npm run coverage:tui on Windows 11 / Node 24.14 gave 2 failed of 639. After: 48 files, 640 tests pass; coverage S 97.51 / B 94.75 / F 97.68 / L 97.83; npm run check in clients/tui exits 0. On POSIX resolve("/d", "a.json") is "/d/a.json", so the assertions are unchanged there (I could not run Linux locally). The change is 12 insertions and 4 deletions in the one test file. For reference only, it is on my fork (I am not opening a PR, per CONTRIBUTING): https://github.com/modelcontextprotocol/inspector/compare/v2/main...Sonica-B:inspector:v2/fix/tui-save-queue-test-windows-paths
AI disclosure (MCP AI_POLICY.md): this report and the fix were produced primarily with Claude Code running on my machine: the Windows test runs, the root-cause analysis, the 16-line test change, and the drafting of this issue.
Before you submit
- I searched existing issues and this is not a duplicate.
- This is not a security vulnerability report (those go through the private advisory process).
- 主要语言
- TypeScript
- 星标
- 11.1k
- 派生
- 1.6k
- 平均合并
- 4 小时 56 分钟
- 30 天内合并 PR
- 155
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/inspector 的其他 Issue
-
local:gate cannot pass on Windows — pre-existing failures in test:scripts, coverage:web and coverage:mcpdo可能已有人在做 @olaservo 于 1 天前认领。 未关闭bug v2
难度 4/5 3-5 天 新手友好度 45/100
modelcontextprotocol/inspector#2748 · 已指派 1 人 ·
维护者通常 1 天内回复
-
blocked chore v2
难度 4/5 3-5 天 新手友好度 48/100
modelcontextprotocol/inspector#2548 · 1 条评论 ·
维护者通常 1 天内回复
-
blocked chore v2
难度 4/5 3-5 天 新手友好度 52/100
modelcontextprotocol/inspector#2547 · 1 条评论 ·
维护者通常 1 天内回复
-
Create the GitHub App for board writes and security-alert reads, and store its credentials as org secrets可能已有人在做 @cliffhall 于 6 天前认领。 未关闭chore v2
难度 4/5 3-5 天 新手友好度 35/100
modelcontextprotocol/inspector#2544 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
chore v2
难度 5/5 一周以上 新手友好度 25/100
modelcontextprotocol/inspector#2543 · 2 条评论 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/inspector 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
openremote/openremote#3487 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 82/100
coollabsio/jean#867 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
ehmpathy/rhachet-roles-bhuild#616 ·
维护者通常 1 天内回复
-
📘 Docs supabase/cli
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 1 天内回复
-
bug(cli): theme file home-directory check uses startsWith (sibling dirs pass, Windows casing fails)未关闭area/core kind/bug priority/p2 status/bot-triaged
难度 2/5 1-3 小时 新手友好度 79/100
google-gemini/gemini-cli#29955 · 2 条评论 ·
维护者通常 1 天内回复