已关闭
refactor: --web 标志在非 TTY 环境下无防护 — 打开浏览器失败导致非零退出 #341
aflyingto创建于  6月26日关闭于  6月27日
aflyingto成员
6月26日 创建

发现来源

Agent 4 - Agent 友好性 (Medium)

位置

pkg/cmd/pr/view/view.go:128-130, pkg/cmd/issue/view/view.go:136-138
pkg/cmd/milestone/view/view.go:123-125, pkg/cmd/release/view/view.go:98-100
pkg/cmd/commit/view/view.go:104-106, pkg/cmd/repo/view/view.go:104-106
pkg/cmd/pr/create/create.go:196-197

证据

所有 view 类命令在 --web 模式下先成功获取并显示资源,然后调用 browser.Open(url)。在无图形环境的 CI 中 browser.Open() 返回错误,导致整个命令非零退出。

影响评估

Agent 可能误判操作失败,实际上资源已成功获取。Agent 不应使用 --web 进行自动化操作,但如果误用会导致错误的失败判断。

建议修复方向

  1. 使用 --web 前检查 CanPrompt() 或 IsStdoutTTY()
  2. 或将浏览器打开失败降级为 stderr 警告但不影响退出码

🤖 Generated by multi-agent code review workflow

likedislike
Aaflyingto成员
6月26日 添加了label:risk/mediumscope/web, status/triage,type/refactor
Aaflyingto成员
6月27日 关联了pull request:fix: downgrade browser open failure to warning in non-TTY environments
Aaflyingto成员
6月27日 添加了label:status/in-progress, status/verified
aflyingto成员
6月27日 评论:

验证记录

  • 验证版本: main (commit e87fc02)
  • 复现命令: grep -rn "browser.Open" pkg/cmd/ --include="*.go"
  • 实际结果: 7 处直接调用 browser.Open(),在 --web 模式下若浏览器打开失败则整个命令非零退出
  • 结论: 问题存在,进入修复

修复实现

在 7 个 view/create 命令中,将 browser.Open() 的失败处理改为 TTY 感知:

  • TTY 环境(交互用户):返回错误,保持原有行为
  • 非 TTY 环境(CI/Agent):打印 stderr 警告,返回 nil(退出码 0)

新增 iostreams.TestTTY() 测试辅助函数 + 2 个单元测试(TTY 失败 / 非 TTY 失败)。

作者自检 9 项

  1. 根因: --web 标志调用 browser.Open() 失败时直接将错误返回,在非 TTY 环境导致误判
  2. 修改范围: 7 个命令文件 + 1 个 iostreams 辅助函数 + 1 个测试文件(create_test.go)
  3. 测试结果: 1250+ tests pass,新增 2 个 browser failure 测试
  4. 实际命令验证: ./gc pr view 1 --web -R infra-test/gctest1 → exit 0 ✓
  5. 安全审查: 无敏感路径改动,仅修改错误处理逻辑
  6. 文档同步: 无需更新(bugfix,不改变命令接口)
  7. 风险点: release/view 文件被风险分级的 keyword 匹配标记为 high,但实际变更与其他 view 文件一致
  8. 未覆盖项: auth/login 的 browser.Open 保持原行为(登录流程中浏览器失败应为真实错误)
  9. CI: https://github.com/gitcode-cli/cli/actions/runs/28277469290

PR

likedislike
Aaflyingto成员
6月27日 关闭了 issue