You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test: two timing-sensitive cases fail merge-queue runs on PRs that do not touch them #7643
Two timing-sensitive test cases failed merge-queue runs for PRs that do not touch their code. Each PR passed the same check on its own CI, and a re-queue merged it.
A mod test, runs each of the worst accepted extra patterns in time linear in the text length, timed out at 5083 ms against its 5000 ms limit. That was in merge-queue run 38913137076's check-plugins job for feat(typos-format): report at commit time through a shared git-hook installer #7547, while the same check passed on the PR head.
Fix
Make both cases independent of runner speed: give the hung-test case a deterministic stand-in for the hang, and measure the linear-time case by its growth ratio rather than a wall-clock limit. Or widen their limits and record how much headroom each gets.
Thanks for the report. I understand this as two separate flaky, timing-sensitive test cases that fail in merge-queue runs on PRs unrelated to their code, then pass on re-queue or on the PR's own CI:
Case 2 looks like a duplicate of #7273, which already covers the same linear-time mask test timing out under a fixed wall-clock budget on a shared runner. Case 1 (the lane-launcher hung-test case) looks new and not yet filed elsewhere.
It may be worth splitting this into a new issue scoped to just the lane-launcher case, since the fix approaches differ (deterministic stand-in for the hang vs. growth-ratio or wider timeout for the linear-time test).
Type: Bug Summary: Make the lane-launcher hung-plugin-test case independent of runner speed.
Current behavior:
The lane-launcher test case a hung plugin test reads unknown (both start and force-bash variants) expects mods: unknown (claude plugin test did not finish in 1 s) and depends on a real hang hitting a 1 s wall-clock limit. It failed in merge-queue run 38949926510 on a PR that does not touch the lanes skill.
Desired behavior:
The case drives the hung claude plugin test path through a deterministic stand-in (for example a stub that never exits, with the launcher's timeout made injectable for the test, or a stub that reports the timeout outcome directly), so the result does not depend on how fast the runner is. The launcher's production timeout and its unknown reading are unchanged.
Key interfaces:
Lane launcher's plugin-test timeout: the value production uses stays the same; the test may override it.
The mods: unknown (claude plugin test did not finish in N s) reading.
This was generated by AI during backlog shaping.Held, not admitted: this brief is drafted and checked, but the issue lane would stop on it today. It is admitted, by adding agent-ready, once the lane can run the skill-quality check scripts (Automation Lanes' PR #7912). Held under the owner's 2026-10-18 lane-narrowing course correction.
Activity
github-actions commentedon Oct 16, 2026
Thanks for the report. I understand this as two separate flaky, timing-sensitive test cases that fail in merge-queue runs on PRs unrelated to their code, then pass on re-queue or on the PR's own CI:
lane-launcher.test.shcase[259]("a hung plugin test reads unknown...") failing in a merge-queue run for feat: move check plugins to commit-time gates and per-batch formatting #7616.Case 2 looks like a duplicate of #7273, which already covers the same linear-time mask test timing out under a fixed wall-clock budget on a shared runner. Case 1 (the lane-launcher hung-test case) looks new and not yet filed elsewhere.
It may be worth splitting this into a new issue scoped to just the lane-launcher case, since the fix approaches differ (deterministic stand-in for the hang vs. growth-ratio or wider timeout for the linear-time test).
Automated triage. A maintainer reviews it.
kyle-sexton commentedon Oct 18, 2026
Agent Brief
Type: Bug
Summary: Make the lane-launcher hung-plugin-test case independent of runner speed.
Current behavior:
The lane-launcher test case
a hung plugin test reads unknown(bothstartand force-bash variants) expectsmods: unknown (claude plugin test did not finish in 1 s)and depends on a real hang hitting a 1 s wall-clock limit. It failed in merge-queue run 38949926510 on a PR that does not touch the lanes skill.Desired behavior:
The case drives the hung
claude plugin testpath through a deterministic stand-in (for example a stub that never exits, with the launcher's timeout made injectable for the test, or a stub that reports the timeout outcome directly), so the result does not depend on how fast the runner is. The launcher's production timeout and itsunknownreading are unchanged.Key interfaces:
mods: unknown (claude plugin test did not finish in N s)reading.Acceptance criteria:
scripts/run-test-file.sh plugins/harness-ops/skills/lanes/scripts/lane-launcher.test.shexits 0.scripts/check-changelog-fragments.shexits 0.Out of scope:
This was generated by AI during backlog shaping. Held, not admitted: this brief is drafted and checked, but the issue lane would stop on it today. It is admitted, by adding
agent-ready, once the lane can run the skill-quality check scripts (Automation Lanes' PR #7912). Held under the owner's 2026-10-18 lane-narrowing course correction.