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
CI: required Check fails on unrelated test timeouts (browser + node suites) #444
Required Check keeps failing on timeouts in tests that the change under test does not touch. This blocks PR merging, and main itself has gone red twice. Under the PR rules (.agents/rules/workflows/pull-requests.md), a retry is allowed only once, and only for an external infrastructure failure, so every one of these timeouts stalls the queue.
effect-json-storetest/concurrency.test.ts › serializes concurrent updates; apps/desktopdaemon-server-process.test.ts › logs unhealthy when a live pid's health probe keeps failing
Test timed out in 5000ms
Most of these failures are in packages the PR did not change (packages/ui, effect-json-store, apps/desktop, tools/verify). Several also passed when run locally on the same head.
Separately, on macOS slash-command-menu.test.tsx › keeps modified and composing Enter out of command selection fails consistently on main (it expects <p>/<br></p>, got <p>/</p> after Ctrl+Enter). It passes on CI's Linux runner, so it's probably a platform keymap difference.
Expected
The required Check is deterministic for a given SHA. A timeout in one test points to a real regression, not runner load.
Suggested direction (to decide)
Find out whether the timeouts correlate with runner contention: Node and Chromium Vitest run in one job, and the browser project and the server/desktop suites run alongside each other.
Fix the individual tests that use short or fixed waits: locator.click with a 337ms budget, and the 5000ms default for real-time polling tests.
Do not raise global timeouts or add automatic retries just to get green. That would hide real regressions and conflicts with the toolchain rules.
Additional observation: all Code check jobs run on a single self-hosted runner (runner-cursor). The jobs run one at a time, each taking about 20–25 minutes. For example, the #435 run 37349027040 was created at 17:31 UTC but did not start until 17:53 UTC. With one shared host running the Chromium browser suites, Node suites and the Desktop e2e, timeouts under load are plausible. Separately, the queue length means every merge (which makes the other PRs behind the strict base) costs each remaining PR a full queue wait.
Another occurrence: @getpie/corebuild-id.test.ts ("uses the first eight characters of HEAD for a clean checkout") and development-scope.test.ts ("reads the current branch and a detached SHA") timed out at 5000 ms on rn-pie-02 (job, PR #432, a rules-only change). Both spawn git; a 5 s default timeout is tight on a loaded single runner.
Another flaky timeout (2026-10-06): app-e2e e2e/product-flows.e2e.test.tsx › session archive › archives the open session from the row menu — right-click the row, then getByRole('menuitem', { name: 'Archive' }) click times out at about 60 s.
The archive-row e2e (product-flows.e2e.test.tsx › session archive › archives the open session from the row menu) has failed again, this time on rn-pie-02: #399db8ef151, run 37438948020. That makes 3 failures out of the last 4 runs on code that includes #449. Since #449, the titlebar title is the first DOM match for getByText(<prompt>).first(), so the right-click can land on the title instead of the sidebar row. A likely fix is to scope the right-click to the sidebar row (e.g. within the session list), as the rename test should too. Raising priority: this now blocks the merge queue.
Pie Session 78781c83 is working on the archive/rename row-menu e2e flake: root cause, a deterministic sidebar-row target, and repeated passes as proof. Its PR will reference this issue.
Another flake (2026-10-06, runner-cursor): tools/verify › isolates parallel runs and rejects another run's CDP owner without touching either browser failed on #399b5d6c44e (run 37440xxx series). The diff under test does not touch tools/verify.
Root cause of the archive row-menu timeout, reproduced locally:
After #449 the session title is portaled into the window titlebar, which is earlier in the DOM than the sidebar. getByText("e2e archive me", { exact: true }).first() therefore hits the titlebar span once that title has rendered. That span has no context menu. The right-click returns, then getByRole("menuitem", { name: "Archive" }) waits out the 60s test timeout.
It is a race, not a product bug. If the click happens before the titlebar title is committed, .first() is still the sidebar row and the menu opens (the local pass). Once the titlebar title is present, the old selector always misses the row. Waiting for [data-app-shell-titlebar-content] to contain the prompt, then using the old click, targeted <span class="min-w-0 truncate" title="e2e archive me"> and timed out on Archive.
The rename test used the same selector. It usually passed because that case stays on /draft, where the titlebar does not show the session title.
Fix is in #459: both row-menu clicks target the sidebar session button. No assertion, retry, or timeout change. e2e/product-flows.e2e.test.tsx passed 6 consecutive runs, 14/14 each. Not merged.
Other flakes on this issue remain (core git-spawn timeouts, single-runner queue), so this issue should stay open.
Another browser-test timeout under CI load, unrelated to the PR's diff: packages/uisrc/ai-elements/reasoning.test.tsx > Reasoning trigger > uses the Tool-style control at the left instead of a right-side chevron — locator.click: Timeout 14890ms exceeded (PR #465, head 667c87ed, which doesn't touch packages/ui). Separately, the intermittent app-e2e getByRole('textbox').first() misses on main 047a49cf were a real regression from #399 (draft hid the composer while models loaded) and are being fixed in #471, not a flake.
Another occurrence after this issue was closed. On PR #454 head bd160539 (base 452feed3), run 37625670216 failed on ui (chromium) src/ai-elements/reasoning.test.tsx > Reasoning trigger > uses the Tool-style control at the left instead of a right-side chevron with TimeoutError: locator.click: Timeout 14892ms exceeded (test took 23.9 s). #454 does not touch packages/ui. The CI-load flake is still present.
Reopening this issue. packages/uisrc/ai-elements/reasoning.test.tsx > "uses the Tool-style control at the left instead of a right-side chevron" (locator.click timeout) failed required CI three times today on unrelated PRs:
Activity
oxwen11 commentedon Oct 5, 2026
Additional observation: all
Code checkjobs run on a single self-hosted runner (runner-cursor). The jobs run one at a time, each taking about 20–25 minutes. For example, the #435 run 37349027040 was created at 17:31 UTC but did not start until 17:53 UTC. With one shared host running the Chromium browser suites, Node suites and the Desktop e2e, timeouts under load are plausible. Separately, the queue length means every merge (which makes the other PRs behind the strict base) costs each remaining PR a full queue wait.oxwen11 commentedon Oct 6, 2026
Another occurrence:
@getpie/corebuild-id.test.ts("uses the first eight characters of HEAD for a clean checkout") anddevelopment-scope.test.ts("reads the current branch and a detached SHA") timed out at 5000 ms on rn-pie-02 (job, PR #432, a rules-only change). Both spawn git; a 5 s default timeout is tight on a loaded single runner.oxwen11 commentedon Oct 6, 2026
Another flaky timeout (2026-10-06): app-e2e
e2e/product-flows.e2e.test.tsx › session archive › archives the open session from the row menu— right-click the row, thengetByRole('menuitem', { name: 'Archive' })click times out at about 60 s.98063ef1(run 37434700908) and fix(app): block new sessions when no models are available #3997693d8cc(run 37435649969).bd1af63aon rn-pie-02 (run 37436396932), plus the full file locally atdb2acfaeand64709013(14/14).So this is not a deterministic regression from fix(app): place the session title in the window titlebar #449.
oxwen11 commentedon Oct 6, 2026
The archive-row e2e (
product-flows.e2e.test.tsx › session archive › archives the open session from the row menu) has failed again, this time on rn-pie-02: #399db8ef151, run 37438948020. That makes 3 failures out of the last 4 runs on code that includes #449. Since #449, the titlebar title is the first DOM match forgetByText(<prompt>).first(), so the right-click can land on the title instead of the sidebar row. A likely fix is to scope the right-click to the sidebar row (e.g. within the session list), as the rename test should too. Raising priority: this now blocks the merge queue.oxwen11 commentedon Oct 6, 2026
Pie Session
78781c83is working on the archive/rename row-menu e2e flake: root cause, a deterministic sidebar-row target, and repeated passes as proof. Its PR will reference this issue.oxwen11 commentedon Oct 6, 2026
Another flake (2026-10-06, runner-cursor):
tools/verify›isolates parallel runs and rejects another run's CDP owner without touching either browserfailed on #399b5d6c44e(run 37440xxx series). The diff under test does not touchtools/verify.oxwen11 commentedon Oct 6, 2026
Root cause of the archive row-menu timeout, reproduced locally:
After #449 the session title is portaled into the window titlebar, which is earlier in the DOM than the sidebar.
getByText("e2e archive me", { exact: true }).first()therefore hits the titlebar span once that title has rendered. That span has no context menu. The right-click returns, thengetByRole("menuitem", { name: "Archive" })waits out the 60s test timeout.It is a race, not a product bug. If the click happens before the titlebar title is committed,
.first()is still the sidebar row and the menu opens (the local pass). Once the titlebar title is present, the old selector always misses the row. Waiting for[data-app-shell-titlebar-content]to contain the prompt, then using the old click, targeted<span class="min-w-0 truncate" title="e2e archive me">and timed out on Archive.The rename test used the same selector. It usually passed because that case stays on
/draft, where the titlebar does not show the session title.Fix is in #459: both row-menu clicks target the sidebar session button. No assertion, retry, or timeout change.
e2e/product-flows.e2e.test.tsxpassed 6 consecutive runs, 14/14 each. Not merged.Other flakes on this issue remain (core git-spawn timeouts, single-runner queue), so this issue should stay open.
oxwen11 commentedon Oct 6, 2026
Another browser-test timeout under CI load, unrelated to the PR's diff:
packages/uisrc/ai-elements/reasoning.test.tsx > Reasoning trigger > uses the Tool-style control at the left instead of a right-side chevron—locator.click: Timeout 14890ms exceeded(PR #465, head667c87ed, which doesn't touch packages/ui). Separately, the intermittent app-e2egetByRole('textbox').first()misses on main047a49cfwere a real regression from #399 (draft hid the composer while models loaded) and are being fixed in #471, not a flake.oxwen11 commentedon Oct 7, 2026
Another occurrence after this issue was closed. On PR #454 head
bd160539(base452feed3), run 37625670216 failed onui (chromium) src/ai-elements/reasoning.test.tsx > Reasoning trigger > uses the Tool-style control at the left instead of a right-side chevronwithTimeoutError: locator.click: Timeout 14892ms exceeded(test took 23.9 s). #454 does not touchpackages/ui. The CI-load flake is still present.oxwen11 commentedon Oct 7, 2026
Reopening this issue.
packages/uisrc/ai-elements/reasoning.test.tsx> "uses the Tool-style control at the left instead of a right-side chevron" (locator.clicktimeout) failed required CI three times today on unrelated PRs:The Developer asked for a Session to make this test robust under CI load.
test(ui): click the reasoning trigger in-page so CI load cannot stall…