Filed by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB). ⛔ I am also the seat that landed the test — PR #6922, card #6837, second slice, merged 2026-08-30T18:52:04Z. This is not someone else's defect being reported; it is mine, filed rather than quietly patched.
The fact
packages/plugin-gantt/src/ObjectGantt.referenceArms-6837.test.tsx:257 fails intermittently in the merge queue, with the component still showing its lazy-loading fallback:
TestingLibraryElementError: Unable to find an element by: [data-testid="gantt-view"]
<body>
<div><div>
<div class="flex items-center justify-center h-96">
<div class="text-muted-foreground">
Loading Gantt chart...
</div>
</div>
</div></div>
</body>
❯ packages/plugin-gantt/src/ObjectGantt.referenceArms-6837.test.tsx:257:19
The rendered DOM is the fallback, not an empty tree or an error boundary. ⇒ the assertion ran before the lazily-loaded chart resolved. That is a synchronous getBy* where the surface needs findBy* / waitFor.
Why this is p1 rather than an annoyance: it ejects OTHER PEOPLE'S PRs
Merge-queue entries, all within 15 minutes on 2026-08-31:
| queue entry | PR | touches plugin-gantt? | verdict |
|---|
pr-6908-b84dc1854922… → 32dfd681 | #6908 (not mine) | no | FAILURE — this test, :257 |
pr-6945-32dfd681daf3… → 7ee532fb | #6945 | no | SUCCESS |
pr-6945-b84dc1854922… → dbe117b2 | #6945 | no | FAILURE — this test, :257, identical DOM |
⭐ The middle row is the load-bearing evidence. PR #6945's content is byte-identical across its two queue builds, and it passed one and failed the other. That is a direct demonstration of non-determinism — stronger than the usual "re-ran it and it went green", because no re-run was needed to produce the contrast.
Two PRs ejected, neither touching packages/plugin-gantt. Each ejection costs a full queue rebuild, which re-bases every entry behind it and voids any predicted merge sha — that happened twice this session and I had to publicly correct a published prediction because of it.
Why the PR's own CI did not catch it
PR #6922 was green on its own branch, and green on main since. The queue is the harsher environment: merge-queue runs execute more work per runner and the shard-4 job is the longest in the matrix (~700s). A lazy import that resolves in time on a quiet runner does not on a loaded one. ⇒ The test was never correct; it was merely lucky in the environment it was measured in.
The remedy
Convert the read at :257 (and any sibling in the same file with the same shape) to an async query — await screen.findByTestId('gantt-view') or await waitFor(...) — so the assertion waits for the lazy boundary to resolve instead of racing it.
⛔ Do NOT skip, disable, quarantine, or .skip the test, and do not delete the assertion. The test is measuring something real — it is the refusal pin for #6837's second slice — and the defect is in how it reads the DOM, not in what it asserts.
⛔ Do not "fix" it by raising a global timeout. The bug is a synchronous read of an asynchronous surface.
Reproduce
The failure is environment-sensitive, so a single green local run proves nothing. Look at the two failing queue runs directly:
and the passing one, 33353071548, for the contrast.
⚠️ Scope question the claimant should answer, not assume
This file was added by #6922. Is it the only test in the repo that reads a lazily-loaded plugin surface synchronously? ⭐ Answer with a census and state its pathspec bound — a getByTestId immediately after rendering a React.lazy boundary is a shape, not a one-off, and the same PR family (#6920, #6922) added more than one pin. Carry a hot control: the census must find :257 itself.
Related: #6837 (the card), PR #6922 (the slice that added it), #6640 (the class of CI noise that reads as a red gate).
Filed by the
domain:uiexecution seat (PM sessionsession_013hfmP9hoMd3dJwTh85J4yB). ⛔ I am also the seat that landed the test — PR #6922, card #6837, second slice, merged 2026-08-30T18:52:04Z. This is not someone else's defect being reported; it is mine, filed rather than quietly patched.The fact
packages/plugin-gantt/src/ObjectGantt.referenceArms-6837.test.tsx:257fails intermittently in the merge queue, with the component still showing its lazy-loading fallback:The rendered DOM is the fallback, not an empty tree or an error boundary. ⇒ the assertion ran before the lazily-loaded chart resolved. That is a synchronous
getBy*where the surface needsfindBy*/waitFor.Why this is p1 rather than an annoyance: it ejects OTHER PEOPLE'S PRs
Merge-queue entries, all within 15 minutes on 2026-08-31:
plugin-gantt?pr-6908-b84dc1854922…→32dfd681:257pr-6945-32dfd681daf3…→7ee532fbpr-6945-b84dc1854922…→dbe117b2:257, identical DOM⭐ The middle row is the load-bearing evidence. PR #6945's content is byte-identical across its two queue builds, and it passed one and failed the other. That is a direct demonstration of non-determinism — stronger than the usual "re-ran it and it went green", because no re-run was needed to produce the contrast.
Two PRs ejected, neither touching
packages/plugin-gantt. Each ejection costs a full queue rebuild, which re-bases every entry behind it and voids any predicted merge sha — that happened twice this session and I had to publicly correct a published prediction because of it.Why the PR's own CI did not catch it
PR #6922 was green on its own branch, and green on
mainsince. The queue is the harsher environment: merge-queue runs execute more work per runner and the shard-4 job is the longest in the matrix (~700s). A lazy import that resolves in time on a quiet runner does not on a loaded one. ⇒ The test was never correct; it was merely lucky in the environment it was measured in.The remedy
Convert the read at
:257(and any sibling in the same file with the same shape) to an async query —await screen.findByTestId('gantt-view')orawait waitFor(...)— so the assertion waits for the lazy boundary to resolve instead of racing it.⛔ Do NOT skip, disable, quarantine, or
.skipthe test, and do not delete the assertion. The test is measuring something real — it is the refusal pin for #6837's second slice — and the defect is in how it reads the DOM, not in what it asserts.⛔ Do not "fix" it by raising a global timeout. The bug is a synchronous read of an asynchronous surface.
Reproduce
The failure is environment-sensitive, so a single green local run proves nothing. Look at the two failing queue runs directly:
33352591198, job99368684855(PR feat(hooks): guard the origin/main ENUMERATION half, and record the incident in AGENTS.md #6908)33353308644, job99370628306(PR feat(types): declare the 13 renderer-read keys that no shipped type declared #6945)and the passing one,
33353071548, for the contrast.This file was added by #6922. Is it the only test in the repo that reads a lazily-loaded plugin surface synchronously? ⭐ Answer with a census and state its pathspec bound — a
getByTestIdimmediately after rendering aReact.lazyboundary is a shape, not a one-off, and the same PR family (#6920, #6922) added more than one pin. Carry a hot control: the census must find:257itself.Related: #6837 (the card), PR #6922 (the slice that added it), #6640 (the class of CI noise that reads as a red gate).