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 }}
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Build & E2E is red on main: the console smoke test finds neither app shell nor loading screen #4086
Found while verifying PR #4084 (issue #4069). Filed unassigned — not caused by
that PR, and outside its scope, but it turns every open PR's Build & E2E gate
red, so it is reported rather than absorbed.
What fails
[chromium] › e2e/smoke.spec.ts:78:3 › Console App – Smoke › should show the app shell or loading screen
1 failed
23 skipped
9 passed (1.8m)
Error: expect(locator).toBeVisible() failed
Locator: locator('nav').first().or(getByText(/Initializing|Loading|Connecting/i).first())
Expected: visible
Error: element(s) not found
- Test timeout of 30000ms exceeded.
at e2e/smoke.spec.ts:88:7
Neither the app shell's nav nor the loading placeholder ever appears, through
all three Playwright retries — the console app does not reach a rendered state at
all, rather than rendering something unexpected.
It is on main, not on a branch
The identical failure — same job, same spec line, same 1 failed / 23 skipped / 9 passed tally — appears on main itself:
9154d9e90 is the merge commit of #4081 (fix(plugin-grid): object-grid publishes the filter key it reads — filter, singular). It is the first run where
this goes red, and the two runs before it are green, so that merge is the prime
suspect — though the smoke test only proves the app never boots, not why, so the
cause is worth confirming rather than assuming.
On PR #4084 that job was the only red of twenty checks; Lint, Type Check and all
four test shards were green.
Why it matters beyond one PR
Build & E2E is not informational (Live E2E is the informational one, and it
passed). While this is red on main, every PR branched from it inherits a red
gate, which is exactly the condition that trains reviewers to merge past reds —
and a genuine regression then rides main's merge ref into every later PR's run
with nothing distinguishing it from the known red.
Suggested first step
Pull the failing run's error-context.md / screenshot attachment (the job
uploads none — No files were found with the provided path: playwright-report/,
which is worth fixing on its own so the artifact survives), or run pnpm exec playwright test e2e/smoke.spec.ts locally against main and read the
browser console at boot.
Claim: PM loop round 4 — main-health, dispatched at top priority (objectui whole-repo seat). target:v17 added: a red required gate on main during the release window blocks every open PR (auto-merge on #4084 is armed and waiting on exactly this) and trains merges past reds.
Session: session_017Qqyix2QcnpUC9XeYVDzx3
Branch: claude/issue-4086-main-smoke-red
Worktree: objectui-issue-4086
Container & model: M, mode:subagent, model: opus
Working hypothesis for the dev to CONFIRM OR REFUTE, not assume: first red is 9154d9e90 (#4081's merge); the two runs before are green; the failure reproduces identically on a second independent run (PR #4084's, branched off that SHA) — so flake is unlikely and #4081 is the prime suspect. #4081's runtime half routes ObjectGrid's $filter through toFilterNode; unit tests, type-check and all four vitest shards are green while the BUILT console never reaches paint — consistent with a build-graph-only failure (e.g. a module-level import cycle or a deep import that the bundler resolves differently than vitest). Disposition ladder: minimal fix-forward if root cause is small and provable; otherwise revert #4081's merge on main (this seat accepted #4081 and explicitly authorizes its revert — reopening #4041 — rather than leaving main red while a fix is engineered).
ACCEPT — with the premise corrected on the record (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3) — PR #4095.
#4081 is exonerated. The evidence is conclusive: main went green at 8497579db with every line of 9154d9e90 still present, then red again at 47737ecb3 (an unrelated dependabot bump) — green/red/green/red across four unrelated commits, the suspect present on both sides. The import-cycle hypothesis this seat put in the claim comment is also structurally impossible (toFilterNode joined an import that already pulled @object-ui/core; the module graph never changed). This seat's working hypothesis was wrong; the dev proved it wrong before touching anything — exactly the discipline the dispatch asked for.
Real cause: a race in the smoke test itself. The signed-out console boots → paints the splash at ~70 ms → redirects to the sign-in screen at ~105 ms and stays there. nav is never entitled to render (no session); the loading text lives ~35 ms. The old assertion (nav OR loading text) only matched a state that exists for a coin-flip window, so runner speed decided the color — which is why it flipped twice today with no related code change. Fix: the assertion now names all three recognised terminal boot states (shell / splash / sign-in), matched structurally (login-config-loading testid, #login-email, #login-phone), keeping the set closed so a blank page or crashed render still fails. Reverse-verified both directions with the settle forced (the honest construction, since the bug IS the race): old assertion red with the CI text verbatim, new one green. Rider fixed: CI's github reporter writes no playwright-report/, so every red run discarded its own evidence — test-results/ (screenshot, trace, error-context) is now uploaded.
On PR #4095: Build & E2E itself is GREEN (the gate this card exists for), along with Type Check / Lint / Control Byte / Changeset Declaration / Build Docs / Live E2E. Shards 1/4 and 2/4 are red — inherited from main's NEXT breakage (this morning's dependabot wave broke two generator-template dependency ratchets), proven unrelated (a vitest shard runs neither e2e/ nor .github/), filed as #4098 and being dispatched at top priority now. #4095 is flipped ready with auto-merge armed and lands when the shards clear; #4084 queues behind the same gate.
Activity
yinlianghui commentedon Aug 10, 2026
Claim: PM loop round 4 — main-health, dispatched at top priority (objectui whole-repo seat).
target:v17added: a red required gate on main during the release window blocks every open PR (auto-merge on #4084 is armed and waiting on exactly this) and trains merges past reds.Session:
session_017Qqyix2QcnpUC9XeYVDzx3Branch:
claude/issue-4086-main-smoke-redWorktree:
objectui-issue-4086Container & model: M,
mode:subagent,model: opusWorking hypothesis for the dev to CONFIRM OR REFUTE, not assume: first red is
9154d9e90(#4081's merge); the two runs before are green; the failure reproduces identically on a second independent run (PR #4084's, branched off that SHA) — so flake is unlikely and #4081 is the prime suspect. #4081's runtime half routes ObjectGrid's$filterthroughtoFilterNode; unit tests, type-check and all four vitest shards are green while the BUILT console never reaches paint — consistent with a build-graph-only failure (e.g. a module-level import cycle or a deep import that the bundler resolves differently than vitest). Disposition ladder: minimal fix-forward if root cause is small and provable; otherwise revert #4081's merge on main (this seat accepted #4081 and explicitly authorizes its revert — reopening #4041 — rather than leaving main red while a fix is engineered).Generated by Claude Code
yinlianghui commentedon Aug 10, 2026
ACCEPT — with the premise corrected on the record (objectui seat PM, session
session_017Qqyix2QcnpUC9XeYVDzx3) — PR #4095.#4081 is exonerated. The evidence is conclusive: main went green at
8497579dbwith every line of9154d9e90still present, then red again at47737ecb3(an unrelated dependabot bump) — green/red/green/red across four unrelated commits, the suspect present on both sides. The import-cycle hypothesis this seat put in the claim comment is also structurally impossible (toFilterNodejoined an import that already pulled@object-ui/core; the module graph never changed). This seat's working hypothesis was wrong; the dev proved it wrong before touching anything — exactly the discipline the dispatch asked for.Real cause: a race in the smoke test itself. The signed-out console boots → paints the splash at ~70 ms → redirects to the sign-in screen at ~105 ms and stays there.
navis never entitled to render (no session); the loading text lives ~35 ms. The old assertion (navOR loading text) only matched a state that exists for a coin-flip window, so runner speed decided the color — which is why it flipped twice today with no related code change. Fix: the assertion now names all three recognised terminal boot states (shell / splash / sign-in), matched structurally (login-config-loadingtestid,#login-email,#login-phone), keeping the set closed so a blank page or crashed render still fails. Reverse-verified both directions with the settle forced (the honest construction, since the bug IS the race): old assertion red with the CI text verbatim, new one green. Rider fixed: CI'sgithubreporter writes noplaywright-report/, so every red run discarded its own evidence —test-results/(screenshot, trace, error-context) is now uploaded.On PR #4095: Build & E2E itself is GREEN (the gate this card exists for), along with Type Check / Lint / Control Byte / Changeset Declaration / Build Docs / Live E2E. Shards 1/4 and 2/4 are red — inherited from main's NEXT breakage (this morning's dependabot wave broke two generator-template dependency ratchets), proven unrelated (a vitest shard runs neither
e2e/nor.github/), filed as #4098 and being dispatched at top priority now. #4095 is flipped ready with auto-merge armed and lands when the shards clear; #4084 queues behind the same gate.Generated by Claude Code
test(e2e): the console smoke test asserts a boot state the app actual…