fix(web-shell): realign two test suites with shipped behavior to unbreak main CI (#11539) - #11549
fix(web-shell): realign two test suites with shipped behavior to unbreak main CI (#11539)#11549qwen-code-dev-bot wants to merge 2 commits into
Conversation
…eak main CI (#11539) Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Autofix E2E Report — Issue #11539What failedMain CI ( Two
The fixTest-only realignment, +17/−1 lines across the two suites:
No production code changed; shipped behavior is untouched. The suites now pin the real behavior: they were red before the alignment (8 failures, output above) and green after — that pre/post run is the mutation probe for a test-only change. Deliberately not in this PRThe main push lane has a second, independent red: Verification
中文说明Autofix E2E 报告 — Issue #11539失败内容主分支 CI(
修复内容仅测试对齐,两个套件合计 +17/−1 行:
未改动任何生产代码;已发布行为保持不变。套件现在锁定的是真实行为:对齐前为红(8 个失败,输出如上),对齐后为绿——对纯测试改动而言,这组前后运行即变异探针。 刻意不纳入本 PR 的内容主分支 push 通道还有第二个相互独立的红: 验证
🧠 Handled by Qwen Code · model/模型 |
github-actions
Bot
added
the
review/self-reported
|
Thanks for the PR — the fix is correct, but it is already on main, and I think this should be closed rather than merged. Template looks good ✓ Problem: real and observed when it was written. Main CI was red on But it has already been fixed. #11530 merged at
The only remaining delta is three words inside comments — "the 404" vs "a 404", "StrictMode's effect remount", "compact**-**footer". There is no behavioural or test-logic difference left to merge. #11539 and #11525 are the same failure reported against two different commits: both name job Direction: the approach is right, because it is literally what main ships. I checked the constants the body cites rather than taking them on faith: Size: not applicable — no core paths touched. Tests-only, +17/−1 across 2 files, 0 production logic lines. Approach: minimal and correctly scoped for the problem it was written against. Nothing to cut, no drive-by changes. Risk: no elevated risk signals — the high-risk path scan matched nothing, both files being web-shell test suites. Why I'm escalating rather than closing it myself: this gate's duplicate-close path only fires when the linked issue is already closed as completed. #11539 is still OPEN, so that precondition is not met, and closing a PR is the one irreversible act in this workflow — I would rather a human make that call than stretch the rule to fit. I flag it here and hand the decision over in the Stage 3 comment. 中文说明感谢贡献 —— 修复本身是正确的，但它已经在 main 上了，我认为这个 PR 应该关闭而不是合并。 模板完整 ✓ 问题： 撰写时是真实且已观测到的。主分支 CI 在 但它已经被修复了。 #11530 于
剩下的差异只有注释里的三个词 —— "the 404" 与 "a 404"、"StrictMode's effect remount"、"compact**-**footer"。已经没有任何行为或测试逻辑上的差异可供合并。 #11539 与 #11525 是同一个失败在两个不同提交上的重复上报：都指向任务 方向： 方案是对的，因为它就是 main 上实际发布的内容。我没有直接采信描述中引用的常量，而是逐一核对： 规模： 不适用 —— 未触及核心路径。纯测试改动，2 个文件 +17/−1，生产逻辑 0 行。 方案： 针对其撰写时的问题，改动最小且范围准确。没有可砍的部分，也没有夹带无关改动。 风险： 无升级风险信号 —— 高风险路径扫描未命中任何文件，两个文件都是 web-shell 测试套件。 为什么我选择上报而不是自行关闭： 本关卡的重复关闭路径只在关联 issue 已被标记为 completed 关闭时才触发。#11539 仍处于 OPEN 状态，该前置条件不成立，而关闭 PR 是整个流程中唯一不可逆的动作 —— 我宁愿由人来做这个决定，也不愿为了套用规则而勉强扩张它。我在这里标记出来，并在 Stage 3 评论中把决定权交出去。 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
Code reviewI formed a view before reading the diff. Given "#11244 added a
That is exactly what this PR does, and exactly what #11530 did. The one alternative I considered — dropping the two tooltip queries and the strict call-count — would have quietly deleted coverage of a shipped feature, so I am glad neither PR took it. Findings: no critical blockers, no AGENTS.md violations. I verified the claims the reasoning rests on rather than accepting them: One trade-off worth naming, which the body already names itself: the loading suite now pins the exact brand-fetch count, so a future provider that legitimately re-fetches the brand has to update this expectation. That is the correct price for a strict boot-sequence assertion, not a defect. Since main already contains this code byte-for-byte, reviewing it here is really reviewing #11530's content — which shipped and is green. CI test evidenceThis is the part a maintainer should look at, and it is not what the PR body implies. The PR's own CI never ran the unit suite. At head
The substitute evidence is main's CI at
The body's numbers — 8 failed / 8 passed pre-fix, 16 passed post-fix, 302 files / 7148 tests for the full package, plus build/typecheck/lint — are the author's own claim, not independently re-run, and on an unattended run I will not execute PR code to check them. That gap does not need a sandboxed lane to close, though: main's green Real-scenario testing: N/A — unattended CI run, and nothing user-visible to drive. 中文说明代码审查我在看 diff 之前先形成了自己的判断。已知「#11244 在
这正是本 PR 的做法，也正是 #11530 的做法。我考虑过的另一种方案——删掉两条 tooltip 查询和严格的调用次数断言——会悄悄抹掉一个已发布功能的覆盖率，所以两个 PR 都没有采用它，这一点我很认同。 结论：无阻断性问题，无 AGENTS.md 违规。 我没有直接采信推理所依赖的前提，而是逐一核对： 有一个取舍值得点明，PR 描述本身也已经点明：loading 套件现在锁定了品牌请求的确切次数，因此未来若 provider 合理地重新获取品牌信息，就必须同步更新该预期。这是严格启动序列断言应付出的正确代价，不是缺陷。 由于 main 上已经逐字节包含了这些代码，在这里审查它实际上就是在审查 #11530 的内容——而它已经合入并且是绿的。 CI 测试证据这是维护者应该关注的部分，而且它与 PR 描述给人的印象并不一致。本 PR 自己的 CI 从未运行单元测试套件。 在 head 替代证据是 main 在
描述中的数字——修复前 8 失败 / 8 通过、修复后 16 通过、全包 302 文件 / 7148 测试，以及 build/typecheck/lint——都是作者自己的声明，未经独立复跑；在无人值守的运行中我不会执行 PR 代码去验证它们。不过这个缺口不需要沙箱通道来补：main 在 真实场景测试：N/A —— 无人值守 CI 运行，且没有可见的用户行为需要驱动。 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
|
Confidence: 3/5 — the code is clean and correct, but this is pure authority, not doubt: the gate has no path to close a duplicate whose linked issue is still open, so a human needs to make that call. Stepping back, this is an unusual one. My independent proposal for the two broken suites was the same fix the PR carries, down to choosing 404 over a real brand payload and choosing to mount above the breakpoint rather than relax the assertion. There is nothing to improve in the diff. But "the diff is right" is not the question — the question is whether there is anything left to merge, and there isn't. Every code line is already on main via #11530; the residue is three words of comment wording. Rebasing this onto main and "reducing it to the remaining delta", which is what I would normally ask for on a duplicate, would mean opening a PR to change "a 404" into "the 404". That is churn with a straight face, so I am not going to ask for it. Six months from now nobody would curse this change — they would just be confused about why it exists. Which points at the thing actually worth a maintainer's attention here, and it is not this PR: The autofix lane filed two issues for one main CI failure — #11525 at commit What I did not do, and why. I am not approving — a second approval on an obsolete, unmergeable PR is worse than none, and Suggested resolution for whoever picks this up:
⏸️ Deferring to @yiliang114 — you merged the identical #11530 twenty-eight minutes before this PR was opened, so the duplicate call is yours rather than mine. Needs a human decision on closing both the PR and #11539. 中文说明Confidence: 3/5 —— 代码干净且正确，但这纯粹是权限问题，而非存疑：本关卡没有路径去关闭一个关联 issue 仍然开启的重复 PR，因此需要人来做这个决定。 退一步看，这是个不太常见的案例。我对这两个损坏套件的独立方案与 PR 所载的修复一致，细到同样选择 404 而非真实品牌数据、同样选择以高于断点的宽度挂载而非放宽断言。diff 里没有可改进之处。但「diff 是对的」并不是问题所在——问题是还有没有东西可合并，而答案是沒有。每一行代码都已通过 #11530 进入 main；残留的只有三处注释措辞。把它 rebase 到 main 并「缩减到剩余差异」——这通常是我对重复 PR 会提的要求——在这里意味着开一个 PR 把 "a 404" 改成 "the 404"。那是正儿八经的无谓改动，所以我不会提这个要求。 六个月后没有人会因为这个改动而骂人——只会疑惑它为什么存在。这恰好指向此处真正值得维护者关注的东西，而它不是这个 PR： autofix 通道为同一次 main CI 失败开了两个 issue——#11525（提交 我没有做的事，以及原因。 我没有批准——在一个已过时、无法合并的 PR 上再投一票比不投更糟，而且 建议的处理方式（给接手的人）：
⏸️ 转交 @yiliang114 —— 你在本 PR 开启前 28 分钟合入了内容相同的 #11530，因此这个重复判定应由你来做，而不是我。需要人来决定是否同时关闭本 PR 与 #11539。 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
|
@qwen-code /resolve |
…ignment The same two web-shell test suites were realigned independently on main by #11530, so this branch's fix and the base branch's landed fix touched the identical lines. The executable code agreed exactly on both sides; only three comment lines differed in phrasing. Take main's already-landed wording, which also matches the neighbouring footer-version suite's "compact footer" term and the shipped SIDEBAR_FOOTER_COMPACT_WIDTH constant. The merge therefore has no net delta against main.
|
Qwen Code resolved the merge conflicts and pushed the branch update. Merge resolution — PR #11549Merge commit Root cause — a duplicate fix, not a feature collision. While this branch was open, main landed Textual, not semantic. Net effect: the merged tree is byte-identical to Load-bearing — the agreed code is the fix itself:
Not verified — no build/lint/tests run (out of scope); I edited only the conflicted files.
中文说明合并提交 根因是重复修复，非功能相撞：本分支开着时 main 已合入 文本冲突，非语义冲突：两文件与 main 各只差三行注释，可执行代码逐字节相同。故无逻辑需合并，只选措辞——保留 main 已合入的写法，它与同目录 关键约束（一致的代码即修复本体）： 未能验证：未运行构建/lint/测试（超出范围），只改动冲突的两个文件。相对 main 的空 diff 属正常，但期望 PR diff 非空的 CI 或评审者可能报警；把 #11549 作为 #11530 的重复项关闭很可能是正确处置（我无法变更 PR 状态）。另 main 有一处未冲突改动： |
Verification report — local real-environment runI built a real local harness for this PR (three Verdict: the fix is correct and it was genuinely needed — but it is already on TL;DR
Arm B is the decisive one: 1. The problem was real (arm A — pre-fix
|
| PR | Branch | Opened | Three-dot diff vs main |
Merge result | Content vs main |
|---|---|---|---|---|---|
| #11542 | autofix/issue-11534 |
07:25:44Z | 2 files, +17 −1 | no net change | byte-identical |
| #11549 (this) | autofix/issue-11539 |
08:19:59Z | empty | no net change | byte-identical |
| #11557 | autofix/issue-11543 |
09:04:03Z | 2 files, +17 −1 | no net change | byte-identical |
#11542 and #11557 still show a +17 −1 diff only because their merge-base predates #11530; I trial-merged both, and each also resolves to zero net change against main.
The root cause is upstream of any of these PRs: main stayed red across four pushes, and one autofix issue was filed per push — #11525, #11534, #11539, #11543 — all for the same two suites. #11525 was fixed and closed by #11530; #11534, #11539 and #11543 are still open even though every commit they name is an ancestor of the fix, so the pipeline kept generating a fresh PR for an already-solved failure.
Recommendation
- Close this PR (and 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 #11557) as already-fixed-on-
main— there is nothing to merge. - Close Main CI failed: Qwen Code CI on 53964ef7e272 #11534, Main CI failed: Qwen Code CI on b1ac3e297023 #11539, Main CI failed: Qwen Code CI on 1097b9fe0af3 #11543 as duplicates of Main CI failed: Qwen Code CI on 13b69b3313da #11525, fixed by fix(web-shell): realign two suites with shipped behavior to unbreak main CI (#11525) #11530.
- Worth considering as a follow-up: have the autofix pipeline dedupe before opening a PR — if an open issue or PR already targets the same failing job/suite, attach to it instead of forking a new branch. This incident cost three redundant PRs and four issues for one defect.
None of this is a criticism of the change itself; the analysis and the patch are both right. They just arrived second.
Harness details / how to reproduce
# three worktrees off this repo
git worktree add --detach arm-A b74592785b # pre-fix main
git worktree add --detach arm-B fe7cf68644 # current origin/main, PR NOT applied
git worktree add --detach arm-C cfcdbf4c4a # this PR's head
# per arm (local node_modules was stale and lacked the workspace link):
ln -s ../../packages/sdk-typescript node_modules/@qwen-code/sdk
(cd packages/acp-bridge && node ../../scripts/build_package.js)
(cd packages/sdk-typescript && node scripts/build.js)
cd packages/web-shell && npx vitest run \
client/components/WorkspaceSessionProvider.loading.test.tsx \
client/components/sidebar/WebShellSidebar.brand.test.tsxpackages/sdk-typescript and packages/acp-bridge are byte-identical across all three arms (same tree hashes), so sharing one build between them is faithful. The @qwen-code/sdk symlink and those two builds are environmental repairs applied identically to every arm; they cannot bias the A/B.
Environment: Linux 6.12.63, Node v22.22.2, vitest 3.2.7, jsdom.
Merge simulation:
git worktree add --detach msim origin/main && cd msim
git merge --no-ff --no-edit pr11549
git diff --stat origin/main HEAD # empty
git rev-parse origin/main^{tree} HEAD^{tree} # identical中文版报告
验证报告 —— 本地真实环境运行
我为这个 PR 搭建了真实的本地验证环境（基于本仓库的三个 git worktree 分臂，跑真实的 vitest，被测代码本身没有任何 mock），并执行了描述中要求的 A/B 对比。
结论：这个修复是正确的，当初也确实需要它 —— 但它已经在 main 上了。合并本 PR 不会带来任何变化。建议关闭而非合并。
结论速览
| 分臂 | 代码树 | 是否应用本 PR | 结果 |
|---|---|---|---|
| A | 修复前的 main b74592785b |
否 | 8 失败 / 8 通过（共 16） —— 与描述预测的失败完全一致 |
| B | 当前 origin/main fe7cf68644 |
否 | 16 全部通过（16） |
| C | 本 PR 的 head cfcdbf4c4a |
是 | 16 全部通过（16） |
B 分臂是决定性的：在不应用本 PR 的情况下，main 上这两个套件已经是绿的。C 分臂与 B 分臂无法区分，因为本 PR 的内容与 main 逐字节相同。
1. 问题当初是真实存在的（A 分臂 —— 修复前的 main）
完整复现，两种失败特征都与描述吻合：loading 套件的 GET /brand 不匹配（非 StrictMode 一次、StrictMode 两次），以及品牌套件两处 expected null not to be null 的 tooltip 查询。
Test Files 2 failed (2)
Tests 8 failed | 8 passed (16)
（截图见英文版第 1 节）
所以描述中的诊断是准确的，这一点没有异议。
2. 但 main 在没有本 PR 的情况下已经是绿的（B 分臂）
同样的命令、同样的环境，在当前 origin/main 上、不应用本 PR：
Test Files 2 passed (2)
Tests 16 passed (16)
修复在本 PR 创建的 28 分钟之前就已经通过兄弟 PR #11530（提交 2488d12d8b，合并于 2026-09-10T07:51:32Z）落地；本 PR 创建于 2026-09-10T08:19:59Z。那次合并也正是红色连续失败后 main 上第一次变绿的 Qwen Code CI。
3. 合并本 PR 在字面意义上是空操作
三项独立检查互相印证：
git diff --stat origin/main...pr11549→ 空。GitHub 也是同样的结论：本 PR 显示changedFiles: 0, +0 −0。- 在干净的
origin/mainworktree 中试合并（git merge --no-ff），得到的树对象是28d72c3c49d7d6d373bd31e0fc422bb3fec7c827，与origin/main自身的树逐字节相同。 - 两个被改文件的
sha256与origin/main完全一致（e540b0c20f96…、c286557d1147…）。
分支自身的合并提交 cfcdbf4c4a 的标题也已经说明了这一点 —— "collapsing a duplicate test realignment"。在 main 前进到 585589ac67 之后复查：依然为空，依然是空操作。
4. 已落地的修复在技术上是站得住的（不变量抽查）
既然这份内容就是 main 上的内容，我没有直接采信，而是核对了它依赖的两个前提：
SIDEBAR_FOOTER_COMPACT_WIDTH = 344（WebShellSidebar.tsx:154），页脚在sidebarWidth < SIDEBAR_FOOTER_COMPACT_WIDTH时进入紧凑态（:2109）。写入的360高于该阈值。✅DaemonWorkspaceProvider.tsx:330将DaemonHttpError && error.status === 404视为"此 daemon 无品牌路由"的确定性应答，并在:334的有界重试路径之前返回。因此 mock 的 404 确实会让该 fetch 立即落定、不启动重试定时器，也不会有杂散调用渗入后续断言。✅
5. 当前 main 上的 web-shell 全量套件
302 个文件 / 7150 个测试，全绿。有一处环境说明需要如实指出：在未构建的 worktree 中，client/build-artifact.test.ts（17 个测试）会因 ENOENT … /packages/web-shell/dist 失败，因为它断言的是构建产物；执行 npm run build 之后 17/17 通过。这是我的验证环境所致，不是 main 的缺陷。（描述中写的是 7148 个测试；我在更新的 tip 上测得 7150，相差三个提交的漂移，无实质影响。）
6. 这是三个完全相同的重复 PR 之一
| PR | 分支 | 创建时间 | 相对 main 的三点 diff |
合并结果 | 与 main 的内容对比 |
|---|---|---|---|---|---|
| #11542 | autofix/issue-11534 |
07:25:44Z | 2 文件，+17 −1 | 无净变化 | 逐字节相同 |
| #11549（本 PR） | autofix/issue-11539 |
08:19:59Z | 空 | 无净变化 | 逐字节相同 |
| #11557 | autofix/issue-11543 |
09:04:03Z | 2 文件，+17 −1 | 无净变化 | 逐字节相同 |
#11542 与 #11557 之所以还显示 +17 −1，只是因为它们的 merge-base 早于 #11530；我对两者都做了试合并，结果同样是相对 main 零净变化。
根本原因在这几个 PR 之上：main 连续四次推送保持红色，每次推送都新建了一个 autofix issue —— #11525、#11534、#11539、#11543，全部指向同样的两个套件。#11525 已由 #11530 修复并关闭；#11534、#11539、#11543 至今仍处于 open，尽管它们所指向的每一个提交都是该修复的祖先，于是流水线持续为一个已解决的失败生成新的 PR。
建议
- 关闭本 PR（以及 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 #11557），理由是修复已在
main上 —— 没有任何内容可供合并。 - 关闭 Main CI failed: Qwen Code CI on 53964ef7e272 #11534、Main CI failed: Qwen Code CI on b1ac3e297023 #11539、Main CI failed: Qwen Code CI on 1097b9fe0af3 #11543，作为 Main CI failed: Qwen Code CI on 13b69b3313da #11525 的重复项（已由 fix(web-shell): realign two suites with shipped behavior to unbreak main CI (#11525) #11530 修复）。
- 值得作为后续改进考虑：让 autofix 流水线在开 PR 之前先去重 —— 如果已有 open 的 issue 或 PR 指向同一个失败的 job/套件，就挂靠到它上面，而不是另开分支。本次事故为一个缺陷付出了三个冗余 PR 和四个 issue 的代价。
以上都不是对这份改动本身的批评；分析和补丁都是对的，只是来晚了一步。
4 participants
What this PR does
Realigns two
packages/web-shelltest suites with the behavior that actually ships on main, unbreaking theTest (ubuntu-latest, Node 22.x)CI lane. Both suites were written against only one side of a feature combination and fail deterministically on main today; the fix is test-only (+17/−1) and changes no production behavior. The workspace-provider loading suite now answers the provider'sGET /brandrequest with a 404 in its mock daemon — the definitive "old daemon has no brand route" answer that settles the fetch instead of arming the provider's retry timer — and expects the brand request alongside the capabilities request in the boot sequence (twice under StrictMode's effect remount). The sidebar brand suite mounts above the compact-footer breakpoint (344px) by seeding the sidebar-width storage key, so the footer version label that carries the brand tooltip renders as its assertions expect.Why it's needed
Main CI failed at
b1ac3e2970(#11539) and is still red at the current tip. The brand-configuration feature (#11244) added aGET /brandfetch besideGET /capabilitiesin the workspace provider, while the loading suite still asserted a capabilities-only boot sequence and its mock daemon threw on the unknown route — an answer the provider treats as a transport failure worthy of a retry timer. Independently, the compact-footer change (#11470) removes the footer version label below a 344px sidebar width, while the brand suite mounts at the default 260px and queries that label's tooltip. Neither is a product defect; the tests simply no longer describe shipped behavior, and every main push reds until they do.A second, independent main-side red — the
qwen-autofix.ymlworkflow-size baseline drift — is deliberately not touched here: it has its own issue (#11529) and open repair PR (#11537), and the ratchet's stale-baseline leniency keeps PR lanes green for branches that do not modify the workflow file (verified locally with the PR-lane base SHA: 208/208 pass).Reviewer Test Plan
How to verify
On main without this PR, run
cd packages/web-shell && npx vitest run client/components/WorkspaceSessionProvider.loading.test.tsx client/components/sidebar/WebShellSidebar.brand.test.tsxand observe 8 failures: the loading suite reportsexpected [ 'GET /capabilities', 'GET /brand' ] to deeply equal [ 'GET /capabilities' ](plus a second brand call under StrictMode), and the brand suite's two version-tooltip queries return null. With this PR the same command passes 16/16, and the full web-shell package suite passes 302 files / 7148 tests. Confirm the loading suite's new expectation matches the provider source:fetchBrandinDaemonWorkspaceProvider.tsxissuesGET /brandper client effect run, and a 404 settles it without a retry. Confirm the brand suite's 360px seed exceedsSIDEBAR_FOOTER_COMPACT_WIDTH(344) inWebShellSidebar.tsx, where the version label renders only when the footer is not compact.Evidence (Before & After)
N/A — test-only change; before/after is the failing vs passing suite output described above.
Tested on
Environment (optional)
N/A — unit tests only (vitest, jsdom).
Risk & Scope
qwen-autofix.ymlworkflow-size baseline drift on the main push lane (owned by Main CI failed: Qwen Code CI on 21951941d726 #11529 / PR fix(ci): record the qwen-autofix.yml size drift two in-allowance PRs accumulated (#11529) #11537); macOS and Windows lanes, left to CI.Linked Issues
Fixes #11539
中文说明
本 PR 做了什么
将
packages/web-shell的两个测试套件与 main 上实际发布的行为对齐,修复Test (ubuntu-latest, Node 22.x)CI 通道。这两个套件编写时只覆盖了某个功能组合的一侧,如今在 main 上确定性失败;本次修复仅涉及测试(+17/−1),不改变任何生产行为。workspace provider 的 loading 套件现在让其 mock daemon 对GET /brand请求返回 404——即"旧 daemon 没有品牌路由"的确定性应答,使该 fetch 立即落定,而不再触发 provider 的重试定时器——并在启动序列断言中预期品牌请求与 capabilities 请求并存(StrictMode 的 effect 重挂载下为两次)。侧边栏品牌套件通过写入侧边栏宽度存储键,以高于紧凑页脚断点(344px)的宽度挂载,使携带品牌 tooltip 的页脚版本标签按断言预期渲染。为什么需要
主分支 CI 在
b1ac3e2970失败(#11539),且在当前顶端仍为红。品牌配置功能(#11244)在 workspace provider 中于GET /capabilities之外新增了GET /brand请求,而 loading 套件仍断言只有 capabilities 的启动序列,其 mock daemon 对未知路由直接抛错——provider 将其视为传输失败并启动重试定时器。另一方面,紧凑页脚改动(#11470)在侧边栏宽度小于 344px 时移除页脚版本标签,而品牌套件以默认 260px 挂载并查询该标签的 tooltip。两者都不是产品缺陷;只是测试不再描述已发布行为,在其修复之前每次 main 推送都会变红。第二个相互独立的 main 侧红色项——
qwen-autofix.yml的 workflow-size 基线漂移——本 PR 刻意不涉及:它有自己的 issue(#11529)和在途修复 PR(#11537),且 ratchet 的过期基线宽免机制会让不修改该 workflow 文件的分支在 PR 通道保持绿色(已在本地用 PR 通道的 base SHA 验证:208/208 通过)。Reviewer 测试计划
如何验证
在不含本 PR 的 main 上运行
cd packages/web-shell && npx vitest run client/components/WorkspaceSessionProvider.loading.test.tsx client/components/sidebar/WebShellSidebar.brand.test.tsx,可观察到 8 个失败:loading 套件报告expected [ 'GET /capabilities', 'GET /brand' ] to deeply equal [ 'GET /capabilities' ](StrictMode 下还有一次额外的品牌请求),品牌套件的两条版本 tooltip 查询返回 null。应用本 PR 后,同一命令 16/16 通过,web-shell 全量套件 302 个文件 / 7148 个测试通过。可对照 provider 源码确认 loading 套件的新预期:DaemonWorkspaceProvider.tsx的fetchBrand在每个 client effect 运行时发起GET /brand,404 会使其落定且不重试。可对照WebShellSidebar.tsx确认品牌套件写入的 360px 高于SIDEBAR_FOOTER_COMPACT_WIDTH(344),版本标签仅在页脚非紧凑时渲染。证据(前后对比)
N/A —— 纯测试改动;前后对比即上文所述的失败与通过的套件输出。
测试平台
环境(可选)
N/A —— 仅单元测试(vitest,jsdom)。
风险与范围
qwen-autofix.ymlworkflow-size 基线漂移(由 Main CI failed: Qwen Code CI on 21951941d726 #11529 / PR fix(ci): record the qwen-autofix.yml size drift two in-allowance PRs accumulated (#11529) #11537 负责);macOS 与 Windows 通道交由 CI 验证。关联 Issue
Fixes #11539