fix(serve): reject fractional max sessions#5705
Conversation
|
@qwen-code /triage |
|
Thanks for the PR! Template looks good ✓ On direction: this fixes a real, well-defined bug — On approach: scope is tight and appropriate. Two files, net +4 lines, no drive-by refactors. The validation ladder ( Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ 方向:这个 PR 修了一个真实、明确的 bug —— 方案:范围紧凑且合适。两个文件、净 +4 行、没有顺手重构。校验顺序( 进入代码审查 🔍 — Qwen Code · qwen3.7-max |
Code reviewThe validation in One small note: The test refactor consolidates three invalid-value cases into No critical correctness bugs, no security holes, no AGENTS.md violations. Diff is tight and focused on the stated goal. Real-scenario testingThe bug lives in the library ( Before / After — validation behaviorRan a Node probe that mirrors the exact validation logic from The effective-cap table at the bottom shows the bug in action: Vitest — new tests fail on old code, pass on new codeThe Vitest — full bridge.test.ts regression run on PR branchAll 299 bridge tests pass — no regressions in session cap, reaper, channel teardown, mid-turn message queue, or the other VerdictThe change is tight, correct, and well-tested. Two minor non-blocking notes (redundant 中文说明代码审查
一个小点: 测试重构把三个非法值用例合并成 没有关键的正确性 bug、没有安全漏洞、没有违反 AGENTS.md。Diff 紧凑,聚焦在声明的目标上。 真实场景测试Bug 在库( 前/后 —— 校验行为跑了一个 Node probe,把 底部的有效上限表清楚地展示了 bug: Vitest —— 新测试在旧代码上失败、在新代码上通过
Vitest —— PR 分支完整 bridge.test.ts 回归全部 299 个 bridge 测试通过 —— session cap、reaper、channel teardown、mid-turn 消息队列、其它 结论改动紧凑、正确、测试充分。两个小的非阻塞备注(多余的 — Qwen Code · qwen3.7-max |
|
Stepping back: this is a small, well-motivated bug fix that does exactly what issue #5704 asks for and nothing more. The validation ladder ( The before/after evidence is unambiguous: My independent proposal would have been essentially the same shape (consolidate the invalid branches, add Approving. Ships the fix cleanly, tests catch the exact bug, no scope creep. 👍 中文说明退一步看:这是一个小而动机明确的 bug fix,完全按照 issue #5704 的要求做,没有多余的东西。校验顺序( 前/后证据很明确: 我自己独立给出的方案基本也是这个形状(合并非法分支、加 通过。修复干净、测试抓到了确切的 bug、没有范围蔓延。👍 — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
|
The PR says fractional values "silently change the effective limit" — but the effective limit for Feel free to reopen with a concrete reproduction. For future PRs, please demonstrate the actual failure rather than "this value could theoretically be passed." 中文说明
PR 说小数值"silently change the effective limit"——但 欢迎带上具体复现案例重新打开。后续 PR 请展示实际失败场景。 |
What this PR does
Rejects fractional
maxSessionsvalues in the ACP session bridge.The existing behavior for
undefined,0, andInfinityis preserved:undefinedkeeps the default session cap, while0andInfinitystill mean unlimited.Why it's needed
maxSessionsis a count-based resource limit. Fractional values like1.5are not meaningful, but they were accepted and then used in acurrent >= maxSessionscomparison.That silently changes the effective limit. For example,
maxSessions: 1.5behaves like allowing 2 sessions. Failing at bridge construction is clearer and matches the nearby integer validation formaxPendingPromptsPerSession.Reviewer Test Plan
How to verify
Run
npm test --workspace=@qwen-code/acp-bridge -- bridge.test.tsand confirm the bridge tests pass.Review the updated
createAcpSessionBridgevalidation and confirm fractionalmaxSessionsvalues now throw while0andInfinityremain valid unlimited sentinels.Evidence (Before & After)
Before:
createAcpSessionBridge({ maxSessions: 1.5 })constructed a bridge and effectively allowed 2 sessions.After: fractional
maxSessionsthrows during bridge construction. Tests coverNaN, negative, and fractional rejection, plus0andInfinityacceptance.Tested on
Environment (optional)
Local validation on macOS:
npm test --workspace=@qwen-code/acp-bridge -- bridge.test.ts✅npx prettier --check packages/acp-bridge/src/bridge.ts packages/acp-bridge/src/bridge.test.ts✅npm run lint --workspace=@qwen-code/acp-bridge --if-present✅npm run typecheck --workspace=@qwen-code/acp-bridge --if-present✅git diff --check✅Risk & Scope
maxSessionswill now fail fast instead of getting an implicit rounded-up effective cap.0,Infinity, and the default behavior are unchanged.Linked Issues
Fixes #5704
AI Assistance Disclosure
I used Codex to review the changes, sanity-check the implementation against existing patterns, and help spot potential edge cases.
中文说明
What this PR does
这个 PR 会在 ACP session bridge 中拒绝小数形式的
maxSessions。原有的
undefined、0和Infinity行为保持不变:undefined使用默认 session 上限,0和Infinity仍然表示无限制。Why it's needed
maxSessions是基于数量的资源限制。像1.5这样的小数没有实际意义,但之前会被接受,并参与current >= maxSessions这样的比较。这会静默改变实际限制。例如
maxSessions: 1.5的效果接近允许 2 个 session。现在在 bridge 构造阶段直接失败更清晰,也和附近maxPendingPromptsPerSession的整数校验保持一致。Reviewer Test Plan
How to verify
运行
npm test --workspace=@qwen-code/acp-bridge -- bridge.test.ts,确认 bridge 测试通过。检查更新后的
createAcpSessionBridge校验逻辑,确认小数maxSessions会抛错,同时0和Infinity仍然是合法的无限制哨兵值。Evidence (Before & After)
Before:
createAcpSessionBridge({ maxSessions: 1.5 })可以构造 bridge,并且实际效果接近允许 2 个 session。After:小数
maxSessions会在 bridge 构造阶段抛错。测试覆盖了NaN、负数、小数拒绝,以及0和Infinity接受。Tested on
Environment (optional)
本地 macOS 验证:
npm test --workspace=@qwen-code/acp-bridge -- bridge.test.ts✅npx prettier --check packages/acp-bridge/src/bridge.ts packages/acp-bridge/src/bridge.test.ts✅npm run lint --workspace=@qwen-code/acp-bridge --if-present✅npm run typecheck --workspace=@qwen-code/acp-bridge --if-present✅git diff --check✅Risk & Scope
maxSessions的 embedded caller 现在会快速失败,而不是得到一个隐式向上取整效果的实际上限。0、Infinity和默认行为都保持不变。Linked Issues
Fixes #5704
AI Assistance Disclosure
I used Codex to review the changes, sanity-check the implementation against existing patterns, and help spot potential edge cases.