TUI and web launcher crash with an unhandled 'error' event when the browser opener cannot be spawned
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 74/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- node.js, typescript
调研方向
Start with clients/tui/src/utils/openUrl.ts and clients/web/server/web-server-config.ts, then compare their browser-opening paths with the CLI fix in #2531. Trace the ChildProcess returned by open(...) and verify both launchers handle spawn failures without crashing, fall back to asking the user to open the URL manually, and cover the shared behavior if a helper is introduced.
由索引模型根据 Issue 内容生成。
描述
Problem
Follow-up to #2531, which fixes the CLI. The TUI and the web launcher call open the same way and have the same defect.
open (10.2.0) resolves with the ChildProcess as soon as it has called spawn(). A spawn failure (ENOENT: the opener binary is missing from PATH) arrives afterwards as an 'error' event on that child. open only listens for it with { wait: true }, and on macOS that option adds open -W, which waits for the browser to quit. With nobody listening, the event crashes the process.
- TUI:
clients/tui/src/utils/openUrl.tsawaitsopen(...)for the OAuth authorization page. A spawn failure crashes the TUI mid-flow. - Web launcher:
clients/web/server/web-server-config.tsopenBrowser()doesopen(url).catch(...). The.catchcovers a rejection but not the child's'error'event, so a spawn failure crashes the web server at startup whenever auto-open is on.
Expected
Both sites handle a spawn failure the way #2531 makes the CLI handle it: listen on the returned child for 'error'/'spawn', chained directly onto open's promise, then fall back to "open the URL manually". A single shared helper would stop the three copies from drifting apart again.
Likelihood
Low on a normal machine (/usr/bin/open on macOS; open ships its own xdg-open on Linux), but real wherever the opener is missing from PATH: minimal containers, sandboxed or env -i launches.
- 主要语言
- TypeScript
- 星标
- 11.1k
- 派生
- 1.6k
- 平均合并
- 4 小时 32 分钟
- 30 天内合并 PR
- 136
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/inspector 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
modelcontextprotocol/inspector#2725 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
modelcontextprotocol/inspector#2723 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
modelcontextprotocol/inspector#2727 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
modelcontextprotocol/inspector#2726 ·
维护者通常 1 天内回复
-
insufficient_scope challenge retry doesn't detect expired access token, gives up after one identical retry可能已有人在做 @its-nott-me 于 4 天前认领。 未关闭bug
难度 3/5 1-2 天 新手友好度 50/100
modelcontextprotocol/inspector#2724 · 4 条评论 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/inspector 的全部 Issue
相似的 Issue
-
area:workflow bug ready-for-human
难度 1/5 1 小时以内 新手友好度 78/100
fil-donadoni/tolaria#6108 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
apache/rocketmq-dashboard#7234 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
vitest-dev/vitest#11656 ·
维护者通常 1 天内回复
-
e2e-failure ready-to-code
难度 2/5 1-3 小时 新手友好度 68/100
redhat-developer/rhdh-plugin-export-overlays#4460 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
ehmpathy/rhachet-roles-bhrain#655 ·
维护者通常 1 天内回复