Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 23 additions & 3 deletions .github/workflows/e2e.yml
Original file line number Diff line number Diff line change
Expand Up @@ -203,10 +203,20 @@ jobs:
# The docker leg runs vitest directly instead of through
# test:integration:sandbox:docker: that script would rebuild the image
# the step above just built.
# external-context-mem0-write, external-context-auto-recall,
# context-compress-interactive and qwen-serve-channel-workers are
# quarantined to the nightly isolated matrix below as a precaution.
Comment on lines +206 to +208

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Critical] R2-1: The comment block no longer asserts the contradicted premise — that half of this blocker is fixed by this commit (verified at HEAD). But its replay core still stands and the Fixes #10316 closing claim is deliberately kept, so the blocker is re-posted under its original id.

The PR still claims Fixes #10316, but #10316's observed failure — main E2E red — completes unchanged after this change. #10316 is the per-commit tracker "Main CI failed: E2E Tests" (run 33091403027). The stall this PR's description narrates was fixed by #10290 before this PR existed: #10272 was closed COMPLETED 58 minutes before this PR opened, and its closing comment retracts the platform hypothesis ("Correction — this is deterministic, not platform-specific … Fixed in #10290"). #10290 is an ancestor of this PR's merge base, yet the PR description still says "the platform-specific stalls remain tracked in #10272. Until that fix lands".

At this PR's exact merge base (7357136, re-verified this round), the only failing files are sdk-typescript/tool-control.test.ts and sdk-typescript/permission-control.test.ts, while all four quarantined suites pass on every leg. This PR excludes neither sdk-typescript suite, so after merge the push E2E workflow still fails on them (post-merge-base runs carry the same signature; one run went fully green without any of these excludes), #10316's incident persists, and merging closes the tracker while removing push-lane coverage from four currently-green suites.

witness:

PR body at head 2ff45c4bf8: "Fixes #10316" … "the platform-specific stalls remain tracked in #10272. Until that fix lands"
issue #10272: state=closed, state_reason=completed, closed_at=2026-08-27T16:20:01Z
  closing comment: "Correction — this is deterministic, not platform-specific … Fixed in #10290"
merge-base run 33130681501 (head_sha=7357136dd1 = this PR's merge base), conclusion=failure:
  Failed Tests = {sdk-typescript/tool-control.test.ts, sdk-typescript/permission-control.test.ts} only
  all four quarantined suites green on every leg (mem0-write passing inside the failing ecs-qwen shard 1/3)
run 33136845731 (post-merge-base): same signature — "Test Files 2 failed | 14 passed | 5 skipped"
run 33139344576: fully green without any of these excludes
git merge-base --is-ancestor 1637aa968b 7357136dd1 → true

Either drop the Fixes #10316 closing claim and reframe the description as a precautionary CI-hygiene change (the description, unlike git history, is editable), or close this PR and re-aim at the sdk-typescript failures that actually keep main red. Maintainer @wenshao has approved this head with the premise objection on record, so the decision is the maintainers' — but the closing claim should not survive this review unchallenged.

中文说明

本 blocker 的注释块部分已由本次提交修复(已在 HEAD 核实):注释不再断言已被推翻的前提。但其重放核心依然成立,且 Fixes #10316 的关闭声明被刻意保留,因此以原 id 重新发布。

本 PR 仍声明 Fixes #10316,但 #10316 所记录的故障 —— main 分支 E2E 红色 —— 在本次改动后原样复现。#10316 是按提交开出的跟踪 issue:"Main CI failed: E2E Tests"(run 33091403027)。PR 描述所叙述的卡住在本 PR 出现之前就已被 #10290 修复:#10272 在本 PR 创建前 58 分钟以 COMPLETED 关闭,其关闭评论纠正了平台假设("Correction — this is deterministic, not platform-specific … Fixed in #10290")。#10290 是本 PR 合并基线的祖先,而 PR 描述仍写着 "the platform-specific stalls remain tracked in #10272. Until that fix lands"。

在本 PR 的精确合并基线(7357136dd1,本轮重新核实)上,唯一失败的文件是 sdk-typescript/tool-control.test.tssdk-typescript/permission-control.test.ts,而四个被隔离的套件在每一个分支上都通过。本 PR 并未排除这两个 sdk-typescript 套件,因此合入后 push E2E 依然会在它们上面失败(合并基线之后的运行保持同样的失败特征;其中一次运行在没有任何这些 exclude 的情况下全绿),#10316 的事故持续存在,而合入会关闭该跟踪 issue,同时把四个当前全绿的套件移出 push 通道。

或移除 Fixes #10316 关闭声明、把描述改写为预防性的 CI 卫生改动(描述与 git 历史不同,是可以编辑的),或关闭本 PR、转而处理真正让 main 保持红色的 sdk-typescript 失败。维护者 @wenshao 已在前提异议在案的情况下批准了当前 head,决定权在维护者 —— 但该关闭声明不应未经质疑地通过本审查。

— qwen3.8-max via Qwen Code /review (v0.22.2)

# Their #10272 startup stalls were the goal-runtime wait bug fixed
# by #10290, not a platform defect, and they have not stalled on
# any platform since. The nightly canaries run on
# ubuntu-latest — which never reproduced the stall — so they keep
# functional coverage on hosted Linux but give no signal about the
# former stall platforms; restoring these suites to the push lanes
# requires verifying them on those runners first.
Comment on lines +213 to +215

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] R1-1: (fix-induced) The rewrite added this round acknowledges the ubuntu-latest canary limitation exactly as this thread asked — but the new wording re-introduces the platform hypothesis that #10272's closing comment explicitly retracts. The same block two lines up says the stalls were "not a platform defect" and "they have not stalled on any platform since", yet these lines invoke "the former stall platforms" and require "verifying them on those runners first" — there are no special stall platforms to re-verify (#10272's closing comment: "Correction — this is deterministic, not platform-specific … 'ubuntu-hosted passes' reflects shard composition"), and the verification the condition demands already happened: at this PR's merge base (run 33130681501) all four suites are green on the macOS and ecs-qwen pool legs. A future maintainer following this lift condition will demand evidence of a platform difference the cited issue says does not exist, so the quarantine never lifts. The sentence start on the two lines above ("ubuntu-latest — which never reproduced the stall") carries the same retracted framing and should be adjusted with it.

Suggested change
# functional coverage on hosted Linux but give no signal about the
# former stall platforms; restoring these suites to the push lanes
# requires verifying them on those runners first.
# functional coverage on hosted Linux. The stall was deterministic
# and was fixed by #10290 (an ancestor of this branch's merge base);
# the suites have been green on every leg since, including macOS and
# the ecs-qwen pool. Lift the quarantine when the canaries are green
# and a maintainer signs off.
中文说明

(修复引发)本轮新增的改写确实按本线程的要求承认了 ubuntu-latest 金丝雀的局限 —— 但新措辞重新引入了 #10272 关闭评论明确纠正过的平台假设。上方两行刚说卡住"并非平台缺陷"且"此后未在任何平台上复现",这几行却又提到"原卡住平台"并要求"先在这些 runner 上验证"—— 并不存在需要重新验证的特殊卡住平台(#10272 关闭评论:"Correction — this is deterministic, not platform-specific … 'ubuntu-hosted passes' reflects shard composition"),而该条件所要求的验证其实已经发生:在本 PR 的合并基线上(run 33130681501),四个套件在 macOS 与 ecs-qwen 池分支上全绿。未来按此解除条件行事的维护者会去索要一份所引 issue 已声明不存在的平台差异证据,隔离因此永远无法解除。上方两行的句首("ubuntu-latest — which never reproduced the stall")带有同样的已被纠正的框架,应一并调整。

— qwen3.8-max via Qwen Code /review (v0.22.2)

if [[ "${{ matrix.sandbox }}" == "sandbox:docker" ]]; then
npx cross-env QWEN_SANDBOX=docker vitest run --root ./integration-tests --exclude '**/interactive/cron-interactive.test.ts' --exclude '**/channel-plugin.test.ts' --shard='${{ matrix.shard }}'
npx cross-env QWEN_SANDBOX=docker vitest run --root ./integration-tests --exclude '**/interactive/cron-interactive.test.ts' --exclude '**/channel-plugin.test.ts' --exclude '**/interactive/external-context-mem0-write.test.ts' --exclude '**/interactive/external-context-auto-recall.test.ts' --exclude '**/interactive/context-compress-interactive.test.ts' --exclude '**/cli/qwen-serve-channel-workers.test.ts' --shard='${{ matrix.shard }}'
else
npm run test:integration:sandbox:none -- --exclude '**/interactive/cron-interactive.test.ts' --exclude '**/channel-plugin.test.ts' --shard='${{ matrix.shard }}'
npm run test:integration:sandbox:none -- --exclude '**/interactive/cron-interactive.test.ts' --exclude '**/channel-plugin.test.ts' --exclude '**/interactive/external-context-mem0-write.test.ts' --exclude '**/interactive/external-context-auto-recall.test.ts' --exclude '**/interactive/context-compress-interactive.test.ts' --exclude '**/cli/qwen-serve-channel-workers.test.ts' --shard='${{ matrix.shard }}'
fi

# The sandbox build retags the same image name every run, so on a
Expand Down Expand Up @@ -275,7 +285,7 @@ jobs:
OPENAI_API_KEY: '${{ secrets.OPENAI_API_KEY }}'
OPENAI_BASE_URL: '${{ secrets.OPENAI_BASE_URL }}'
OPENAI_MODEL: '${{ secrets.OPENAI_MODEL }}'
run: 'npx cross-env VERBOSE=true KEEP_OUTPUT=true QWEN_SANDBOX=false vitest run --root ./integration-tests --exclude "**/interactive/cron-interactive.test.ts" --exclude "**/channel-plugin.test.ts" --shard="${{ matrix.shard }}"'
run: 'npx cross-env VERBOSE=true KEEP_OUTPUT=true QWEN_SANDBOX=false vitest run --root ./integration-tests --exclude "**/interactive/cron-interactive.test.ts" --exclude "**/channel-plugin.test.ts" --exclude "**/interactive/external-context-mem0-write.test.ts" --exclude "**/interactive/external-context-auto-recall.test.ts" --exclude "**/interactive/context-compress-interactive.test.ts" --exclude "**/cli/qwen-serve-channel-workers.test.ts" --shard="${{ matrix.shard }}"'

isolated-nightly:
name: '${{ matrix.label }} (nightly)'
Expand All @@ -291,6 +301,16 @@ jobs:
test_file: 'interactive/cron-interactive.test.ts'
- label: 'channel-plugin E2E'
test_file: 'channel-plugin.test.ts'
# Quarantined from the push lanes as a precaution; see the
# excludes and rationale in the push jobs above.
- label: 'external-context-mem0-write E2E'
test_file: 'interactive/external-context-mem0-write.test.ts'
Comment on lines +306 to +307

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] The canary entries live in isolated-nightly, which is runs-on: 'ubuntu-latest' with continue-on-error: true — the one platform where the #10272 stall does not reproduce — so they can never go red for the defect they quarantine. The PR body states the quarantine's exit condition as "whether #10290's goal-runtime fix already resolved the stalls will show up as green nightly canaries, which is the evidence to lift the quarantine" — but these suites were already green on ubuntu-hosted while the stall was live (#10272), so green canaries can never distinguish "fixed" from "still stalling on macOS/ecs-qwen". A maintainer following that documented process would restore the suites to the push lanes and reintroduce the stall. Either give the canary entries a runs-on matrix dimension that includes a stalling platform, or — minimum fix — rewrite the comment added above to state that the ubuntu canaries preserve functional coverage on hosted Linux only and provide no signal about the #10272 stall, so lifting the quarantine requires verification on a stalling platform.

中文说明

这些金丝雀条目所在的 isolated-nightlyruns-on: 'ubuntu-latest'continue-on-error: true —— 恰是 #10272 卡住不会复现的平台 —— 因此它们永远不会为其所隔离的缺陷变红。PR 描述把解除隔离的退出条件写成"#10290 的 goal-runtime 修复是否已解决卡住,将表现为夜间金丝雀变绿,那即是解除隔离的证据" —— 但在卡住仍然存活时,这些套件在 ubuntu-hosted 上本来就是绿的(#10272 的证据),所以绿色的金丝雀无法区分"已修复"与"仍在 macOS/ecs-qwen 上卡住"。维护者按此文档化流程操作会把套件恢复到 push 通道,重新引入卡住。建议给金丝雀条目加一个包含卡住平台的 runs-on 矩阵维度,或至少把上方新增的注释改写为:ubuntu 金丝雀仅在托管 Linux 上保留功能覆盖,对 #10272 卡住不提供任何信号,解除隔离前需在卡住平台上验证。

— qwen3.8-max via Qwen Code /review (v0.22.2)

- label: 'external-context-auto-recall E2E'
test_file: 'interactive/external-context-auto-recall.test.ts'
- label: 'context-compress-interactive E2E'
test_file: 'interactive/context-compress-interactive.test.ts'
- label: 'qwen-serve-channel-workers E2E'
test_file: 'cli/qwen-serve-channel-workers.test.ts'
steps:
- name: 'Checkout'
uses: 'actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10' # v6.0.3
Expand Down
68 changes: 67 additions & 1 deletion scripts/tests/e2e-workflow.test.js
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
* SPDX-License-Identifier: Apache-2.0
*/

import { readFileSync } from 'node:fs';
import { existsSync, readFileSync } from 'node:fs';
import { describe, expect, it } from 'vitest';
import { parse } from 'yaml';

Expand Down Expand Up @@ -32,4 +32,70 @@ describe('e2e workflow', () => {
expect(group).toContain('github.event_name');
expect(group).toContain('github.head_ref || github.ref_name');
});

it('quarantines the nightly-isolated suites from every push lane', () => {
// cron-interactive is timing-flaky, and external-context-mem0-write,
// external-context-auto-recall, context-compress-interactive and
// qwen-serve-channel-workers are quarantined to the nightly isolated
// matrix as a precaution after the #10272 startup stalls (since traced
// to the goal-runtime wait bug fixed by #10290). Every nightly canary
// must be excluded from every push lane, and every push-lane exclusion
// must keep its nightly canary — dropping either side silently loses
// coverage.
const nightlyFiles = yml.jobs['isolated-nightly'].strategy.matrix.include

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] R3-1: The pin test derives its expected exclude set solely from e2e.yml's own isolated-nightly matrix, so it asserts a relational invariant (canaries ⇔ excludes) rather than the quarantine's existence — a full revert of the e2e.yml change passes all 4 tests, i.e. the quarantine ships with nothing gating it. Measured at the merge base this round: with merge-base e2e.yml restored over the PR version, the suite passes 4/4, identical to HEAD, because the pre-PR state (2 canaries, 2 matching excludes) satisfies the same invariant. A git revert of the workflow change — or any edit that drops the four excludes and the four nightly entries together — therefore passes CI while silently returning all four suites to every push lane. Single-hunk reverts are caught; only the symmetric removal survives. (Recorded in round 2's deferral list; re-measured after this round's pin-test hardening and still open.)

// after the nightlyFiles computation — pin the quarantined membership
// absolutely, alongside the relational check:
for (const file of [
  'interactive/external-context-mem0-write.test.ts',
  'interactive/external-context-auto-recall.test.ts',
  'interactive/context-compress-interactive.test.ts',
  'cli/qwen-serve-channel-workers.test.ts',
]) {
  expect(nightlyFiles, file).toContain(file);
}

Fix witness: with the membership pin added, revert this PR's e2e.yml hunks (e.g. git show 7357136dd1:.github/workflows/e2e.yml > .github/workflows/e2e.yml) and confirm this test goes red — it stays green today.

中文说明

钉桩测试的期望排除集完全取自 e2e.yml 自身的 isolated-nightly 矩阵,因此它断言的是一个关系型不变量(金丝雀 ⇔ 排除项),而不是隔离本身的存在 —— 完整回退 e2e.yml 改动后 4 个测试全部通过,也就是说隔离落地时没有任何东西为其兜底。本轮已在合并基线上实测:用合并基线的 e2e.yml 覆盖 PR 版本后重跑该套件,4/4 通过,与 HEAD 完全一致,因为 PR 之前的状态(2 个金丝雀、2 个匹配的排除项)同样满足该不变量。因此,对工作流改动做 git revert —— 或任何同时删掉四个排除项与四个夜间条目的编辑 —— 都能通过 CI,同时把四个套件悄悄送回每一条 push 通道。单侧回退会被捕捉;只有对称删除能够幸存。(该问题已记录于第 2 轮的延后列表;本轮钉桩加固后重新测量,依然存在。)

修复见证:加入成员资格钉桩后,回退本 PR 的 e2e.yml 改动(例如 git show 7357136dd1:.github/workflows/e2e.yml > .github/workflows/e2e.yml),确认本测试变红 —— 当前它保持绿色。

— qwen3.8-max via Qwen Code /review (v0.22.2)

.map((entry) => entry.test_file)
.sort();
Comment on lines +45 to +47

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] The pin test's oracle is closed inside e2e.yml: the push-lane --exclude strings are compared against the nightly matrix test_file strings only — neither side is ever checked against the real files under integration-tests/. If a future PR renames a quarantined suite without touching e2e.yml, the excludes match nothing (vitest ignores a non-matching --exclude silently), the suite is un-quarantined and stalls the push lanes again — the exact regression this PR fixes — while the nightly canary finds no file, exits 1, and continue-on-error: true paints it green. The test stays green throughout, so the scenario its own comment names ("dropping either side silently loses coverage") happens with the guard watching. Verified by probe at this commit: renaming cli/qwen-serve-channel-workers.test.ts left the test 3/3 green and vitest list still listed the renamed file despite the exclude; adding an existsSync assertion flipped the probe red/green correctly.

Anchor the pin to the filesystem — for example:

import { existsSync } from 'node:fs';
// inside the test:
for (const file of nightlyFiles) {
  expect(existsSync(`integration-tests/${file}`)).toBe(true);
}

Fix witness: with that assertion in place, renaming any of the six quarantined suites without updating e2e.yml turns this test red — remove the fix and confirm the test fails.

中文说明

钉桩测试的对照范围封闭在 e2e.yml 内部:push 通道的 --exclude 字符串只与夜间矩阵的 test_file 字符串互相比较,两侧都没有对照 integration-tests/ 下的真实文件。若未来某个 PR 重命名了被隔离的套件而未改 e2e.yml,exclude 会悄悄匹配不到任何文件(vitest 对不匹配的 --exclude 静默忽略),该套件随即被解除隔离并再次卡住 push 通道 —— 正是本 PR 要修复的回归;与此同时,夜间金丝雀找不到文件、以退出码 1 结束,而 continue-on-error: true 会把红色刷成绿色。本测试全程保持绿色,因此测试自身注释所命名的场景("任何一侧被悄悄删掉都会丢失覆盖")会在守卫在场时发生。已在本次提交上探针验证:重命名 cli/qwen-serve-channel-workers.test.ts 后测试仍 3/3 通过,且 vitest list 在存在 exclude 的情况下仍列出重命名后的文件;加入 existsSync 断言后探针正确翻转(红/绿)。

建议把钉桩锚定到文件系统,例如:

import { existsSync } from 'node:fs';
// 测试内:
for (const file of nightlyFiles) {
  expect(existsSync(`integration-tests/${file}`)).toBe(true);
}

修复见证:加入该断言后,重命名六个被隔离套件中的任意一个而不更新 e2e.yml,都会让本测试变红 —— 请移除该修复并确认测试失败。

— qwen3.8-max via Qwen Code /review (v0.22.2)

Comment on lines +45 to +47

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] The canary side is verified only as matrix include entries — nothing in this test reads isolated-nightly's run step, so it never checks that the step actually consumes ${{ matrix.test_file }}. A future edit to that step — dropping the "${{ matrix.test_file }}" positional, replacing it with a hardcoded filter, or copying the push lanes' command with its --exclude list — silently neuters all six canaries (they run nothing, or exclude exactly the suites they exist to run), while continue-on-error: true masks any red and this test stays green. This hole is orthogonal to the filesystem-anchoring gap above; neither fix closes the other. Verified by probe at this commit: dropping the positional left the test 3/3 green; adding the assertion below flipped it red, and it is green against the current workflow.

const canaryStep = yml.jobs['isolated-nightly'].steps.find(
  (s) => s.name === 'Run ${{ matrix.label }} tests',
);
expect(canaryStep.run).toContain('${{ matrix.test_file }}');

Fix witness: deleting "${{ matrix.test_file }}" from the Run ${{ matrix.label }} tests command in e2e.yml must turn the new assertion red — remove the fix and confirm the test fails.

中文说明

金丝雀一侧只被验证为矩阵 include 条目 —— 本测试没有任何断言读取 isolated-nightly 的运行步骤,因此从不检查该步骤是否真的消费 ${{ matrix.test_file }}。未来对该步骤的任何编辑 —— 删掉 "${{ matrix.test_file }}" 位置参数、换成硬编码过滤器、或把 push 通道那条带 --exclude 列表的命令复制过来 —— 都会悄悄使全部六个金丝雀失效(它们要么什么都不运行,要么恰好排除掉自己本应运行的套件),而 continue-on-error: true 会掩盖任何红色,本测试保持绿色。此缺口与上面的文件系统锚定缺口正交,两个修复互不覆盖。已在本次提交上探针验证:删除位置参数后测试仍 3/3 通过;加入下面的断言后翻转为红,在当前 workflow 上为绿。

const canaryStep = yml.jobs['isolated-nightly'].steps.find(
  (s) => s.name === 'Run ${{ matrix.label }} tests',
);
expect(canaryStep.run).toContain('${{ matrix.test_file }}');

修复见证:从 e2e.yml 的 Run ${{ matrix.label }} tests 命令中删除 "${{ matrix.test_file }}",新断言必须变红 —— 请移除该修复并确认测试失败。

— qwen3.8-max via Qwen Code /review (v0.22.2)

// Anchor the oracle to the filesystem: a renamed suite would otherwise
// match no exclude (vitest ignores a non-matching --exclude silently)
// and no canary file while this test compared e2e.yml strings only.
for (const file of nightlyFiles) {
expect(existsSync(`integration-tests/${file}`), file).toBe(true);
}
Comment on lines +51 to +53

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] R1-2: (fix-induced) The existsSync anchor added this round as this thread's fix checks that a canary path exists on disk, but not that vitest will ever collect it. A suite moved under a directory that integration-tests/vitest.config.ts excludes (hook-integration/**, **/terminal-bench/*.test.ts, the qwen-daemon-loadtest* / qwen-daemon-first-output-benchmark* files) — with the nightly matrix and both push-lane exclude globs updated to the new path in the same edit — keeps this test green while the suite stops running anywhere: the push-lane --excludes match nothing (silently ignored), the canary filter collects nothing so vitest exits 1, and continue-on-error: true reports that as success. Probed in a scratch tree at this commit: repointing one canary and its three exclude sites at the real file hook-integration/hooks.test.ts leaves all 4 tests green today, and the canary leg itself exits 1 with "No test files found" — the pin written to catch silent coverage loss certifies it.

Suggested change
for (const file of nightlyFiles) {
expect(existsSync(`integration-tests/${file}`), file).toBe(true);
}
for (const file of nightlyFiles) {
expect(existsSync(`integration-tests/${file}`), file).toBe(true);
// A path under one of integration-tests/vitest.config.ts's excludes
// exists but is never collected — the pin would certify a suite that
// runs nowhere.
expect(file.endsWith('.test.ts'), file).toBe(true);
expect(
/^(hook-integration|terminal-bench)\//.test(file) ||
file.includes('qwen-daemon-loadtest') ||
file.includes('qwen-daemon-first-output-benchmark'),
file,
).toBe(false);
}

Fix witness: with the collectability assertions in place, point one canary entry and its push-lane excludes at a real file under hook-integration/ and confirm this test goes red — then remove the assertions and confirm it is green again under the same mutation.

中文说明

(修复引发)本轮作为本线程修复而加入的 existsSync 锚点只检查金丝雀路径存在于磁盘,并不检查 vitest 是否会收集它。把一个套件移入 integration-tests/vitest.config.ts 所排除的目录(hook-integration/****/terminal-bench/*.test.tsqwen-daemon-loadtest* / qwen-daemon-first-output-benchmark*),并在同一次编辑里把夜间矩阵与两个 push 通道的 exclude 通配符都更新为新路径 —— 本测试依然绿色,而该套件从此在任何地方都不再运行:push 通道的 --exclude 匹配不到任何文件(被静默忽略),金丝雀的过滤器收集不到任何文件、vitest 以退出码 1 结束,continue-on-error: true 又把它刷成成功。已在本提交的临时树中探针验证:把一个金丝雀及其三处 exclude 改指向真实文件 hook-integration/hooks.test.ts,当前 4 个测试全部保持绿色,而金丝雀分支自身以 "No test files found" 退出码 1 结束 —— 本为捕捉静默覆盖丢失而写的钉桩反而为其背书。

修复见证:加入可收集性断言后,把一个金丝雀条目及其 push 通道 exclude 指向 hook-integration/ 下的真实文件,确认本测试变红 —— 再移除这些断言,确认同一变异下测试重新变绿。

— qwen3.8-max via Qwen Code /review (v0.22.2)

const countExcludes = (run) => {
const counts = new Map();
for (const match of run.matchAll(/--exclude ['"]([^'"]+)['"]/g)) {
const file = match[1].replace(/^\*\*\//, '');
counts.set(file, (counts.get(file) ?? 0) + 1);
}
return counts;
};
// Discover push lanes instead of listing job names: every job with a
// `Run E2E tests` step is one, so a future lane that forgets the
// excludes fails here instead of stalling on the quarantined suites.
Comment on lines +62 to +64

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] R1-4: (fix-induced) The lane discovery added this round as this thread's fix is keyed on the step name Run E2E tests, and the lanes > 0 tripwire only fires if every lane loses that name — so renaming the run step of one lane silently removes that lane from the oracle while the test stays green. This thread asked for discovery plus leg-count expectations "keyed by name for the two known jobs so structural changes still fail loud"; the identity half is what is missing. Probed in a scratch tree at this commit: renaming e2e-test-linux's step to Run tests leaves all 4 tests green (e2e-test-macos alone satisfies the tripwire), and additionally dropping the four quarantine excludes from the renamed lane ALSO passes — the quarantined suites re-enter a push lane with the guard watching.

// in the discovery loop, next to `lanes += 1;`:
laneJobs.push(jobName);

// next to `expect(lanes).toBeGreaterThan(0);`:
expect(laneJobs.sort()).toEqual(['e2e-test-linux', 'e2e-test-macos']);

Fix witness: with the lane-identity assertion in place, rename one lane's Run E2E tests step and confirm this test goes red — then remove the assertion and confirm it is green again under the same mutation.

中文说明

(修复引发)本轮作为本线程修复而加入的通道发现以步骤名 Run E2E tests 为键,而 lanes > 0 绊线只有在所有通道都失去该名称时才会触发 —— 因此重命名某一个通道的运行步骤会把它悄悄移出神谕,而测试依然绿色。本线程当初要求的是"发现通道 + 按名称键控的两个已知通道的分支计数期望,使结构变化仍能响亮地失败";缺失的正是身份这一半。已在本提交的临时树中探针验证:把 e2e-test-linux 的步骤改名为 Run tests,4 个测试全部保持绿色(仅 e2e-test-macos 即可满足绊线);再从该改名通道中删掉四个隔离 exclude,测试依然通过 —— 被隔离的套件在守卫在场时重新进入 push 通道。

修复见证:加入通道身份断言后,重命名某个通道的 Run E2E tests 步骤,确认本测试变红 —— 再移除该断言,确认同一变异下测试重新变绿。

— qwen3.8-max via Qwen Code /review (v0.22.2)

let lanes = 0;
for (const [jobName, job] of Object.entries(yml.jobs)) {
const step = job.steps.find((s) => s.name === 'Run E2E tests');
if (!step) continue;
lanes += 1;
// One vitest invocation per matrix leg; counting them separately
// catches an exclude moved between legs, which a whole-step count
// cancels out.
const invocations = step.run
.split('\n')
.filter((line) => !line.trim().startsWith('#'))
.filter((line) => /vitest run|test:integration/.test(line));
expect(invocations.length, jobName).toBeGreaterThan(0);
for (const invocation of invocations) {
const counts = countExcludes(invocation);
expect([...counts.keys()].sort(), `${jobName}: ${invocation}`).toEqual(
nightlyFiles,
);
for (const file of nightlyFiles) {
expect(counts.get(file), `${jobName}: ${file}`).toBe(1);
}
}
}
expect(lanes).toBeGreaterThan(0);
});

it('runs the nightly canary step on its matrix file', () => {
// The quarantine test above pins the canary matrix against the push
// lanes but never reads the canary run step: if that step stopped
// consuming matrix.test_file, every canary would silently run nothing
// while continue-on-error painted the jobs green.
const canaryStep = yml.jobs['isolated-nightly'].steps.find(
(step) => step.name === 'Run ${{ matrix.label }} tests',
);
expect(canaryStep.run).toContain('${{ matrix.test_file }}');
});
});
Loading