fix(web-shell): unbreak brand probe and version-tooltip test assertions (#11535) - #11552
fix(web-shell): unbreak brand probe and version-tooltip test assertions (#11535)#11552qwen-code-dev-bot wants to merge 2 commits into
Conversation
…ns (#11535) The workspace provider's loading test asserted the cold-start request list as exactly ['GET /capabilities'], but the brand feature (#11244) added a once-per-client GET /brand probe, and the mock's catch-all throw also scheduled the provider's 2s brand retry. Answer the probe with a 404 — the response that settles it without a retry — and include it in the expected list (twice under StrictMode, which mounts twice). The sidebar brand tests asserted the version tooltip at the default 260px width, but the version row only renders above the 344px compact footer breakpoint (#6522/#11453). Mount those two cases at 360px, the same convention as WebShellSidebar.footer-version.test.tsx. Both failures were deterministic on main since #11244 merged and red every post-merge Test (ubuntu-latest) run since, including d8baa87. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Autofix E2E Report — Issue #11535What the issue reported
Root cause (with evidence)The PTY commit is innocent. The standing red on main was introduced one commit earlier by
Reproduced locally at HEAD with the CI environment (
All five involved files are byte-identical between Fix (test-only, 2 files, +14/−1 lines)
No production code changed: the pinned behaviors are the intended ones (the brand probe is a designed once-per-client fetch; the compact footer hiding the version label is the deliberate #6522/#11453 behavior). Out of scope (observed, not caused by this red series)
VerificationAll run with CI-like env (
Mutation check: the "fix" here is the test update itself; the pre-fix state fails 8/8 of the targeted tests and the post-fix state passes them (shown above), so the pins are live, not vacuous. 中文说明Autofix E2E 报告 — Issue #11535问题现象main 分支在 根因（含证据）该 PTY 提交是无辜的。main 的持续红灯是由早一个提交的
最后一次绿灯与首次红灯之间只有 在 HEAD 用 CI 环境（
涉及的五个文件在 修复（仅测试，2 个文件，+14/−1 行）
未改动任何生产代码：所钉住的行为都是设计本意（brand 探测是设计好的每客户端一次拉取；紧凑页脚隐藏版本标签是 #6522/#11453 的刻意行为）。 不在本次范围（已观察到，但并非本轮红灯的原因）
验证均在 Linux 上以类 CI 环境（重定向
变异检查：这里的"修复"就是测试更新本身；修复前 8/8 个目标测试失败、修复后全部通过（如上所示），说明这些断言是真实生效的，而非空转。 🧠 Handled by Qwen Code · model/模型 |
github-actions
Bot
added
the
review/self-reported
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
@qwen-code-dev-bot stopping this before code review: the failure it repairs was already fixed on main about half an hour before this branch's commit was authored, so there is no delta left to merge.
What landed first. #11530 (commit 2488d12d8b, merged 2026-09-10 07:51 UTC) repaired exactly these two Web Shell suites for exactly this failure — Test (ubuntu-latest, Node 22.x) red in Run tests and generate reports — and closed #11525 with it. Test (ubuntu-latest, Node 22.x) on 2488d12d8b is success. This PR's single commit eec79aecd is dated 08:22 UTC and the PR opened at 08:33 UTC, so the autofix run was working from a checkout that predates #11530.
Main already contains every line this PR adds.
WorkspaceSessionProvider.loading.test.tsx— main already answers/brandwith a 404 in the fetch mock (line 111), and already assertsstrictMode ? ['GET /capabilities', 'GET /brand', 'GET /brand'] : ['GET /capabilities', 'GET /brand'](lines 205-210). Same route, same status, same StrictMode cardinality as this PR's patch.WebShellSidebar.brand.test.tsx— main already setsqwen-code-web-shell-sidebar-widthto360(line 168), and does it once inbeforeEachinstead of per test, so it covers both tooltip cases patched here plus every other case in the file. Main's shape is the better of the two.
GitHub agrees the hunks have diverged: the PR reports mergeable: CONFLICTING / mergeStateStatus: DIRTY against base tip 0ef35351e9. A rebase onto main would leave an empty diff.
So the call here is that the problem no longer exists at this PR's own base — not that the analysis was wrong. The reading of #11244's once-per-client brand probe and of the 344px compact-footer breakpoint is correct, and independently matches what #11530 shipped; these tests no longer contradict shipped behavior.
What should happen instead
- Nothing to merge — this can be closed as superseded by #11530.
- #11535 is a per-commit CI-failure issue filed against
d8baa8730f(06:24 UTC), which predates the #11530 fix. Its root cause is already repaired, so it should be closed as completed rather than driving another repair PR. - For whoever owns the autofix lane: this duplicate came from branching on a stale base. A pre-flight re-check — "is
Test (ubuntu-latest, Node 22.x)still red on current main for this failure signature?" — before opening would have caught it, and would spare a green main a conflicting no-op PR. No maintainer is @mentioned because the owner resolver has no area forpackages/web-shell/paths and this PR has no human reviewer yet.
Not verified, and moot given the above: there is no PR-side test evidence either way. Only pull_request_target orchestration ran on eec79aecd — no pull_request workflow runs — so this PR's own CI never reached the unit suite. The author's local run is their claim, not evidence, and I did not re-run it.
中文说明
@qwen-code-dev-bot 在进入代码审查前先拦下这个 PR：它要修的那个失败，在本分支提交产生前约半小时就已经在 main 上修好了，因此已经没有可合入的增量。
先落地的是哪一个。 #11530（提交 2488d12d8b，2026-09-10 07:51 UTC 合入）修的正是这两个 Web Shell 测试套件、正是这个失败——Test (ubuntu-latest, Node 22.x) 在 Run tests and generate reports 步骤红灯——并随之关闭了 #11525。2488d12d8b 上的 Test (ubuntu-latest, Node 22.x) 结论为 success。而本 PR 唯一的提交 eec79aecd 时间是 08:22 UTC，PR 开于 08:33 UTC，也就是说这次 autofix 运行所基于的检出早于 #11530。
本 PR 新增的每一行，main 上都已经有了。
WorkspaceSessionProvider.loading.test.tsx——main 的 fetch mock 已经用 404 应答/brand（第 111 行），并且已经断言strictMode ? ['GET /capabilities', 'GET /brand', 'GET /brand'] : ['GET /capabilities', 'GET /brand']（第 205-210 行）。路由、状态码、StrictMode 下的请求次数都与本 PR 的补丁一致。WebShellSidebar.brand.test.tsx——main 已经把qwen-code-web-shell-sidebar-width设为360（第 168 行），而且是放在beforeEach里一次性设置、不是逐个用例设置，因此它既覆盖了本 PR 单独打补丁的两个 tooltip 用例，也覆盖了该文件里的其他所有用例。main 的写法是两者中更好的那个。
GitHub 也认为这些代码块已经分叉：本 PR 相对 base tip 0ef35351e9 的状态是 mergeable: CONFLICTING / mergeStateStatus: DIRTY。变基到 main 之后 diff 会是空的。
所以这里的判断是问题在本 PR 自己的 base 上已不复存在——而不是说它的分析有错。它对 #11244 每客户端一次的品牌探测、以及 344px 紧凑页脚断点的理解都是正确的，并且与 #11530 独立落地的实现相互印证；这两个测试文件已经不再与已发布的行为相矛盾。
建议的处理方式
- 无可合入内容——可以作为被 #11530 取代而关闭。
- #11535 是针对
d8baa8730f（06:24 UTC）按提交建档的 CI 失败 issue，早于 #11530 的修复。其根因已修复，应当以 completed 关闭，而不是再驱动一个修复 PR。 - 给 autofix 链路的负责人：这个重复 PR 源自基于陈旧 base 建分支。开 PR 前先复查一次——"当前 main 上
Test (ubuntu-latest, Node 22.x)对这个失败特征是否仍然红灯？"——就能拦住它，也能让已经绿灯的 main 少收一个冲突的空操作 PR。这里没有 @ 维护者，因为 owner 解析策略里没有对应packages/web-shell/路径的 area，且本 PR 目前还没有人类 reviewer。
未验证（鉴于上述结论，已无关紧要）：本 PR 自身没有任何测试证据。eec79aecd 上只跑了 pull_request_target 编排任务——没有 pull_request 工作流运行——因此本 PR 自己的 CI 从未跑到单元测试套件。作者在本地跑出的结果属于作者自述，不是证据，我也没有重跑。
— Qwen Code · qwen3.8-max-2026-09-02
|
@qwen-code /resolve |
…main shipped Commit 2488d12 from #11530 independently landed the same two web-shell test realignments this PR makes, so both sides edited the same logic rather than adjacent lines. WorkspaceSessionProvider.loading.test.tsx has a single fetch mock, and each side added a GET /brand 404 arm to it plus the identical strictMode-conditional calls assertion. The merge auto-combined both arms into the same if-chain, leaving the later endsWith-based arm unreachable behind the earlier exact-match arm from main. Keep the exact match: it cannot swallow an unrelated path into the brand reply, and it sits beside the other exact-match arm for /capabilities. WebShellSidebar.brand.test.tsx auto-merged without conflict. Main sets the 360px sidebar width once in beforeEach, which already covers the two tests this PR set it in, so those per-test writes survive as idempotent no-ops. Left as merged because the file did not conflict.
|
Qwen Code resolved the merge conflicts and pushed the branch update. Root causeTwo independent fixes for the same red CI, not adjacent edits. Main's Semantic; main subsumes this PR
// kept (main, ~L108): exact match
if (url.pathname === '/brand') return new Response('not found', { status: 404 });
// dropped (this PR, ~L189): unreachable behind it
if (url.pathname.endsWith('/brand')) return new Response('not found', { status: 404 });The file is now byte-identical to Load-bearing
Could not verifyNo build, typecheck, or tests were run.
中文说明冲突根因两个针对同一 CI 红灯的独立修复，非相邻改动。main 的 语义冲突，main 已覆盖本 PR该测试只有一个 fetch mock。双方都加了 关键约束
未能验证未执行构建、类型检查或测试。
|
🖼️ 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 |
Local verification of #11552 — real build, real browserVerdict: the diagnosis in this PR is correct, but there is nothing left to merge. The failure it repairs was fixed on Harness. Dedicated worktree at this PR's head ( What I confirmed
1 · The bug is real; it is also already fixed
2 · The four remaining lines are inertMain sets the sidebar width once in
3 · Why 360 px — checked against the shipped UI, not just the testBoth fixes rest on the claim that the version row is hidden below the compact-footer breakpoint. I verified that claim outside the test that asserts it: Playwright drives the real web-shell against the repo's own mock daemon (
4 · Where the delta went, and two stale numbers in the body
RecommendationClose as superseded by #11530. Merging is harmless — CI would stay green — but it lands two per-test writes of a value the file's own Reprogit worktree add /tmp/wt-11552 <pr-head> && cd /tmp/wt-11552 && npm ci
cd packages/web-shell
# C — PR head
npx vitest run --config vitest.config.ts \
components/WorkspaceSessionProvider.loading.test.tsx \
components/sidebar/WebShellSidebar.brand.test.tsx # 16/16
# B — same worktree, main tip, PR not applied
git checkout fe7cf68644 && (rerun) # 16/16
# A — main immediately before #11530
git checkout b74592785b && (rerun) # 8 failed / 8 passed
# D — PR head with its own diff removed
git checkout pr-head && git checkout origin/main -- \
client/components/sidebar/WebShellSidebar.brand.test.tsx && (rerun) # 16/16Not verified
中文版（合并参考）本地验证 #11552 —— 真实构建、真实浏览器结论：本 PR 的分析是对的，但已经没有可合入的增量。 它要修的失败，已由 #11530（ 环境。 在本 PR head（ 已确认的事实
1 · Bug 是真的，但也确实已经修好了
2 · 剩下的 4 行是空操作main 在
3 · 为什么是 360px —— 对着实际发布的 UI 验证，而不是只看测试两边的修法都建立在“版本行在紧凑页脚断点以下被隐藏”这个前提上。我在断言它的那个测试之外独立验证了这一点：用 Playwright 驱动真实 web-shell，后端用仓库自带的 mock daemon（
4 · 增量去哪了，以及正文里两个已经过时的数字
建议作为被 #11530 取代关闭。 合了也无害，CI 依然会绿；但它会留下两处“重复写入一个 未验证
|
3 participants
What this PR does
Repairs two Web Shell test files that have been failing on every main CI run since the brand feature landed, turning the post-merge
Test (ubuntu-latest, Node 22.x)step red on six consecutive commits. The workspace provider loading test now accounts for the provider's once-per-clientGET /brandprobe: the fetch mock answers the route with a 404 (the response that settles the probe without scheduling the provider's 2 s retry) and the cold-start request assertion includes it. The sidebar brand test's two version-tooltip cases now mount at a sidebar width above the compact-footer breakpoint, because the version row is deliberately hidden below it.Why it's needed
Main has been red since
13b69b3313(#11244) introduced the brand fetch and the brand sidebar tests: that change added the probe without updating the loading test's exact request-list assertion (the loading test landed earlier in #11413), and its own two tooltip assertions could never pass at the default 260 px sidebar width because the version row only renders at 344 px and up (#6522/#11453). Every main push since — including #11535'sd8baa8730fand the current tip — fails the unit-test step, and the per-commit failure issues carry no test names because job logs are not machine-readable by the filing workflow here. No production behavior is wrong; the tests as written contradict two intended behaviors, so this PR fixes the tests and leaves the implementation untouched.Reviewer Test Plan
How to verify
Check out this branch and run the Web Shell suite:
cd packages/web-shell && npx vitest run --config vitest.config.ts components/WorkspaceSessionProvider.loading.test.tsx components/sidebar/WebShellSidebar.brand.test.tsx. Expect all 16 tests green. For the full picture,npx vitest run --config vitest.config.tsin the same package should report 301 files / 7138 tests passed. On main without this PR, the same commands fail 8 tests across these two files.Evidence (Before & After)
N/A — test-only change, no UI behavior change. Before:
WorkspaceSessionProvider.loading.test.tsxfails 6 cases withexpected [ 'GET /capabilities', 'GET /brand' ] to deeply equal [ 'GET /capabilities' ], andWebShellSidebar.brand.test.tsxfails 2 cases withexpected null not to be nullon the version tooltip selector. After: both files pass.Tested on
Environment (optional)
N/A — unit tests only (jsdom; no daemon, no browser).
Risk & Scope
session-writer-leasein core,conversation-runtime-ownershipin cli) time out in the local container used for this verification but were green in the last passing main CI run and are unchanged here;verify-captureand the workflow-size ratchet need CI-provided fonts/WORKFLOW_SIZE_BASE_SHAand are likewise untouched.Linked Issues
Fixes #11535
中文说明
本 PR 做了什么
修复了自品牌功能合入后在每次 main CI 运行中都失败的两个 Web Shell 测试文件——这导致六个连续提交的 post-merge
Test (ubuntu-latest, Node 22.x)步骤一直红灯。workspace provider 的加载测试现在考虑了 provider 每个客户端挂载时一次的GET /brand探测：fetch mock 用 404 应答该路由（这是能让探测落定且不触发 provider 2 秒重试的响应），冷启动请求序列断言也包含了这次探测。侧栏品牌测试的两个版本 tooltip 用例改为在高于紧凑页脚断点的侧栏宽度下挂载，因为版本行在该断点以下是被刻意隐藏的。为什么需要
自
13b69b3313（#11244）引入品牌拉取和品牌侧栏测试以来，main 一直红灯：该改动新增了探测请求，却没有更新加载测试的精确请求序列断言（加载测试更早，来自 #11413）；而它自己新增的两个 tooltip 断言在默认 260px 侧栏宽度下根本不可能通过，因为版本行只在 344px 及以上才渲染（#6522/#11453）。此后的每个 main push——包括 #11535 对应的d8baa8730f和当前最新提交——都失败在单元测试步骤；按提交建档的 failure issue 里没有测试名，是因为该建档工作流无法机读 job 日志。生产行为本身没有错：这两处测试的写法与两个设计本意相矛盾，因此本 PR 只修测试、不动实现。评审者测试计划
如何验证
检出本分支并运行 Web Shell 套件：
cd packages/web-shell && npx vitest run --config vitest.config.ts components/WorkspaceSessionProvider.loading.test.tsx components/sidebar/WebShellSidebar.brand.test.tsx，预期 16 个测试全绿。更完整地看，同目录下npx vitest run --config vitest.config.ts应报告 301 个文件 / 7138 个测试通过。在没有本 PR 的 main 上，相同命令会在这两个文件中失败 8 个测试。前后对比证据
N/A —— 仅测试改动，无 UI 行为变化。修复前：
WorkspaceSessionProvider.loading.test.tsx失败 6 例，报expected [ 'GET /capabilities', 'GET /brand' ] to deeply equal [ 'GET /capabilities' ]；WebShellSidebar.brand.test.tsx失败 2 例，版本 tooltip 选择器报expected null not to be null。修复后：两个文件全部通过。测试平台
环境（可选）
N/A —— 仅单元测试（jsdom；无 daemon、无浏览器）。
风险与范围
session-writer-lease、cli 的conversation-runtime-ownership）在本次验证所用的本地容器中超时，但它们在最近一次通过的 main CI 运行中是绿的，且本 PR 未触碰；verify-capture与工作流体积棘轮需要 CI 提供的字体/WORKFLOW_SIZE_BASE_SHA，同样未改动。关联 Issue
Fixes #11535