fix(web-shell): realign two suites with shipped behavior to unbreak main CI (#11534) - #11542
fix(web-shell): realign two suites with shipped behavior to unbreak main CI (#11534)#11542qwen-code-dev-bot wants to merge 4 commits into
Conversation
…ain CI (#11534) The brand PR #11244 landed on top of #11470 and left two web-shell suites failing on main, redding the Test job (run 34443429185): - The sidebar brand tests assert the version tooltip's title while mounting at the default 260px width, but #11470 hides the version label below the 344px compact footer breakpoint, so the query finds nothing. Mount those brand tests at 360px, matching the convention of the footer-version suite. - The workspace-session loading test pins the exact daemon requests issued on load, but the workspace provider now fetches GET /brand beside capabilities. Answer it with a 404 (an older daemon without the route, which settles the fetch instead of arming the retry timer) and expect the call, including the StrictMode remount double. Both are test-environment alignments; no production behavior changes.
Autofix Report — Issue #11534IssueA main-branch CI run on DiagnosisThe failing commit itself only touched
The rest of the web-shell suite (298 files / 7105 tests) was green before the change, confirming the scope. FixTest-environment alignments only; no production behavior changes, and no assertion weakened:
Mutation probe: for this test-only change the probe is inherent — the updated assertions were red on the pre-fix tree (8 failures reproduced above) and green after the edit, which is exactly the witness that they pin the new alignment. No production guard or branch was added, so there is nothing further to mutate. Verification
Note: a sibling autofix branch for the earlier same-signature issue #11525 ( 中文说明Autofix 报告 — Issue #11534问题
诊断失败的提交本身只改动了
套件其余部分(298 个文件 / 7105 个测试)在修改前全部为绿,确认了影响范围。 修复仅对齐测试环境;不改变任何生产行为,也未削弱任何断言:
变异探针:对本次纯测试修改而言,探针是天然成立的——更新后的断言在修复前的代码树上为红(上方复现的 8 个失败),修改后转绿,这恰好证明它们固定了新的对齐行为。本次未新增任何生产守卫或分支,因此没有更多可变异的对象。 验证
注:针对更早的同一签名 issue #11525 的姊妹 autofix 分支( 🧠 Handled by Qwen Code · model/模型 |
github-actions
Bot
added
the
review/self-reported
|
✅ Qwen Triage finished — CI landed green on ✅ Qwen Triage 已完成 —— |
|
Thanks for the PR! Template looks good ✓ — every required heading is filled in, and the bilingual body is a real translation rather than a stub. Problem: observed, not theoretical, and I confirmed it independently rather than taking the description's word for it. I pulled the log for the failing job the linked issue names (run
That last line is the useful one: main really is issuing Direction: aligned. A required check is red on Size: 0 production lines, 18 test lines (17 additions / 1 deletion) across 2 files, 0 generated/schema. No core paths, so the core-module gate does not apply and there is nothing to escalate on size. Approach: minimal, and I could not find a smaller correct version. One thing to settle before this merges, though:
Risk: no elevated risk signals. The revert-history path check matched nothing — both changed files are Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ —— 所有必需小节都已填写，中英文正文是真正的对照翻译而非占位。 问题： 是已观测到的问题，不是理论性加固；而且我没有只采信 PR 描述，而是独立核实过。我拉取了关联 issue 所指失败任务的日志（run
最后一条尤为关键：main 上确实会在挂载时发出 方向： 对齐。 规模： 生产代码 0 行，测试代码 18 行（新增 17 / 删除 1），涉及 2 个文件，生成/schema 0 行。未触及核心路径，因此核心模块门禁不适用，也无需就规模上报。 方案： 足够精简，我没能找到更小的正确版本。但合入前有一件事需要定夺：
风险： 无升级风险信号。回滚历史路径检查未命中 —— 两个变更文件都是 进入代码审查 🔍 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
🖼️ web-shell visual previewRendered against a mock daemon (no real backend): the PR base vs this PR head Screenshots · before / after✅ No screenshot changes against the PR base. Full-resolution recordings (.webm) are attached to the workflow run. — Qwen Code · web-shell visuals |
Code reviewNo correctness blockers, and nothing that reads as an AGENTS.md violation. I went looking for the failure mode this shape of PR usually hides — a test "aligned with shipped behavior" that is really a regression being quietly accepted — and both edits check out against the production code. Details, because the reasoning is what makes this safe to merge: The sidebar edit fixes a stale fixture, not a masked bug. Two things I specifically wanted to be sure of:
Because the width goes into the shared The 404 fixture is the correct one, not merely a convenient one. The StrictMode asymmetry is real, and the PR documents rather than papers over it. Nothing else in the file needed touching. Every later Two non-blocking notes:
The 18 added lines are all load-bearing for the stated goal: no drive-by refactors, no formatting churn, no unrelated edits. The comments are why-comments with issue references, which is the house style. Test evidenceUnattended CI run, so per the gate's rules I did not build or execute anything from this PR — the evidence below is this repo's own CI read through the API, plus the base-branch failure log I pulled independently in Stage 1. The base half of the claim is confirmed from real logs: job The head half is not yet settled: the decisive lane is still running at the time of writing. Everything else that has finished is green, including Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 Skipped by the workflow's own path filtering, so there is no signal to read either way: Attribution, so this is not mistaken for evidence: the body reports 16/16 on the two suites and a full-package 300 files / 7113 tests green on the author's local Linux checkout. That is the author's own result and I did not re-run it. The pending No sandboxed lane needed here, and I want to be explicit about why rather than just omit it. The central claim is "these two suites fail on main and pass with this change" — which is precisely what 中文说明代码审查没有正确性阻塞项，也没有违反 AGENTS.md 的地方。我特意去找这类 PR 常见的隐藏问题——所谓"与已发布行为对齐"实际上是把一个回归悄悄接受下来——两处修改对照生产代码后都站得住。理由如下，因为正是这些推理让它可以放心合入： 侧边栏那处修改修的是过期夹具，不是被掩盖的 bug。 有两点我特别要确认：
由于宽度写在共享的 404 夹具是正确选择，而不只是方便的选择。 StrictMode 下的不对称是真实存在的，而 PR 选择把它写清楚而非掩盖。 文件中没有别处需要改动。 后续所有 两条非阻塞提醒：
新增的 18 行全部服务于既定目标：没有顺手重构，没有格式化噪声，没有无关改动。注释都是带 issue 编号的"为什么"注释，符合本项目风格。 测试证据本次为无人值守 CI 运行，按门禁规则我没有构建或执行本 PR 的任何代码——以下证据来自通过 API 读取的本仓库自身 CI，外加我在 Stage 1 独立拉取的基线分支失败日志。 主张的基线一侧已由真实日志确认：run head 一侧尚未定论：撰写时决定性通道仍在运行。其余已完成的全部为绿，包括 上方表格中的 CI 状态由收尾工作流在 CI 结束后原地更新。 工作流自身路径过滤所跳过的检查（ 归属声明，以免被误当作证据： 正文称在其本地 Linux 检出上两个套件 16/16 通过、整包 300 文件 / 7113 测试全绿。这是作者自己的结果，我没有重跑。上方待定的 此处不需要沙箱验证通道，我想明确说明理由而不是直接略过。 核心主张是"这两个套件在 main 上失败、应用本改动后通过"——而这恰恰由 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
|
Confidence: 4/5 — the code is correct as far as static review can establish and I could not break it; the two open items are a duplicate PR and an unfinished CI lane, neither of which is a defect in this diff. My independent proposal, written before I read the diff, was the same two moves: mount the brand suite above the compact breakpoint, and teach the loading mock about the brand route while updating the request pin. The only place I would have differed is mechanical — I would probably have added a per-test width helper mirroring the sibling suite rather than putting the width in the shared The reason I am comfortable approving a bot-authored, test-only PR that makes failing tests pass — which is precisely the shape where an agent gets green by weakening an assertion — is that I checked for exactly that and it did not happen. The request pin gets stricter: an exact-equality array grows to include a request the runtime genuinely issues, and it stays an exact array rather than becoming a superset or a The numbers all line up against production source rather than against the PR's own narrative: 260 default versus the 344 breakpoint, a max-width clamp of Six months from now this reads fine. The three comments cite the issues that explain the breakpoint and the brand fetch, so the next person does not have to reverse-engineer why the width is 360 or why the fixture answers 404. If anything the change leaves the suite better covered than it found it: this file drives the real Two things I am not pretending are resolved:
Not a blocker, and I would not change it today: the StrictMode branch of the pin now asserts that the brand fetch is not deduplicated in flight. That is accurate dev-mode behavior, but it means a future improvement — giving 中文说明信心度：4/5 —— 就静态审查所能确立的范围而言，代码是正确的，我没能找出破绽；两个未决事项是一个重复 PR 和一条尚未跑完的 CI 通道，二者都不是本 diff 的缺陷。 我在读 diff 之前独立形成的方案，与 PR 的做法是同两步：让品牌套件在紧凑断点之上挂载，并让加载 mock 认识品牌路由、同时更新请求固定断言。唯一会不同的是机械层面——我大概会照同目录套件的样子加一个按测试指定宽度的辅助函数，而不是把宽度写进共享的 我之所以能放心批准一个由 bot 提交、纯粹改测试、且作用是让失败测试通过的 PR——这正是 agent 最容易靠削弱断言换取绿灯的形态——是因为我专门查了这一点，而它没有发生。请求固定断言反而更严格：一个全等数组扩充到包含运行时确实会发出的请求，并且仍是全等数组，没有退化成超集或 所有数字都与生产源码对得上，而不是与 PR 自己的叙述对得上：默认 260 对断点 344；最大宽度钳制为 半年后再看也没问题。三条注释都引用了解释断点与品牌请求的 issue，因此后来者无需反推宽度为何是 360、夹具为何应答 404。如果说有什么变化，这套件被留下的覆盖比原来更好：本文件驱动的是真实的 有两件事我不打算粉饰：
不构成阻塞，我今天也不会去改它：请求固定断言的 StrictMode 分支现在断言的是品牌请求在途未被去重。这确实是开发态的真实行为，但意味着日后一项改进——给 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
|
Qwen Code review timed out. Qwen review timed out after 5400 seconds (of the 90-minute budget). For large PRs, retry with a longer timeout by commenting: |
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： Autofix review round — no actionNo code change was made this round. There was no actionable feedback to Feedback triage
PR health spot-checkThe two suites this PR touches were run locally and pass:
中文说明Autofix 审查轮次 —— 无需改动本轮没有进行任何代码改动,因为没有需要处理的可执行反馈。 反馈分诊
PR 健康状况抽查本 PR 涉及的两个测试套件已在本地运行并通过:
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
|
🔀 Base updated: red check(s) [review-pr] pass on current main — merged current main via update-branch; CI will re-run. 中文说明🔀 已更新 base：红色检查 [review-pr] 在当前 main 上通过 —— 已通过 update-branch 合入当前 main，CI 将重新运行。 |
2 participants
What this PR does
Realigns two web-shell test suites with the behavior that actually ships on main, unbreaking the
Test (ubuntu-latest, Node 22.x)CI lane. The brand-configuration feature landed on top of the compact-footer change and the two suites were written against only one side of that combination: the sidebar brand tests mount at the default 260px width while asserting a footer version tooltip that the compact footer breakpoint (344px) now hides, and the workspace-session loading test pins the exact daemon requests issued on load without accounting for the brand fetch the provider now issues beside capabilities. The brand suite now mounts above the compact breakpoint (matching the footer-version suite's convention), and the loading suite answers the brand route with a 404 — an older daemon without the route — so the provider's brand fetch settles immediately instead of arming its retry timer, with the expected-call pin updated to include it. No production code changes; no assertion is weakened (the request pin becomes stricter).Why it's needed
Main CI is red: the run on
53964ef7e2failed in the Test job's unit-test step, and the failure reproduces deterministically on the current tree — 8 tests across the two suites. Every main push keeps failing this required check until the suites match shipped behavior.Reviewer Test Plan
How to verify
Check out main without this PR and run the two suites in
packages/web-shell:npx vitest run --config vitest.config.ts client/components/sidebar/WebShellSidebar.brand.test.tsx client/components/WorkspaceSessionProvider.loading.test.tsx. Expected: 8 failures — two tooltip-title assertions find no element (expected null not to be null), and six loading variants fail the exact-request pin with extraGET /brandcalls. With this PR, the same command passes 16/16, and the full web-shell suite passes 300 files / 7113 tests. A reviewer should also confirm the assertions still test the real contract: the tooltip title still must read<brand name> v<version>, and the loading test still pins the exact request sequence (now including the brand fetch) rather than a superset.Evidence (Before & After)
N/A (test-only change; no user-visible behavior). Before: 8 failed / 8 passed across the two suites. After: 16 / 16 passed, full package green.
Tested on
Environment (optional)
Local Linux checkout, Node 22,
npx vitest runinpackages/web-shellplus repo-widenpm run build,npm run typecheck,npm run lint— all green.Risk & Scope
Linked Issues
Fixes #11534
中文说明
本 PR 做了什么
将两个 web-shell 测试套件与 main 上实际发布的行为重新对齐,修复
Test (ubuntu-latest, Node 22.x)CI 通道。品牌可配置功能合入时叠加在紧凑页脚改动之上,而这两个套件编写时只考虑了其中一侧:侧边栏品牌测试以默认 260px 宽度挂载,却断言一个会被紧凑页脚断点(344px)隐藏的页脚版本工具提示;工作区会话加载测试精确固定了加载时发出的守护进程请求,却没有计入提供方现在随 capabilities 一同发出的品牌请求。品牌套件现在改为在紧凑断点之上挂载(与 footer-version 套件的约定一致),加载套件则以 404 应答品牌路由——即不带该路由的旧版守护进程的响应——使提供方的品牌请求立即终结,而不再触发重试定时器,同时更新了预期调用断言以包含该请求。不改动任何生产代码;未削弱任何断言(请求固定断言反而更严格)。为什么需要
main CI 当前为红:
53964ef7e2上的运行在 Test 任务的单元测试步骤失败,且该失败在当前代码树上可确定性复现——两个套件共 8 个测试失败。在套件与已发布行为对齐之前,每次 main 推送都会继续卡在这个必需检查上。审查者测试计划
如何验证
在不包含本 PR 的 main 上检出代码,并在
packages/web-shell中运行这两个套件:npx vitest run --config vitest.config.ts client/components/sidebar/WebShellSidebar.brand.test.tsx client/components/WorkspaceSessionProvider.loading.test.tsx。预期:8 个失败——两个工具提示标题断言查不到元素(expected null not to be null),六个加载变体因多出GET /brand调用而在精确请求断言上失败。应用本 PR 后,同一命令 16/16 通过,完整 web-shell 套件 300 个文件 / 7113 个测试全部通过。审查者还应确认断言仍在测试真实契约:工具提示标题仍必须是<品牌名> v<版本>,加载测试仍固定精确的请求序列(现在包含品牌请求),而非一个超集。前后对比(证据)
N/A(纯测试改动;无用户可见行为)。修复前:两个套件 8 失败 / 8 通过。修复后:16 / 16 通过,整个包为绿。
已测试平台
环境(可选)
本地 Linux 检出,Node 22,在
packages/web-shell中运行npx vitest run,以及仓库级npm run build、npm run typecheck、npm run lint——全部通过。风险与范围
关联 Issue
修复 #11534(Fixes #11534)