[finding] ObjectGantt.referenceArms-6837.test.tsx races its own mount — sync getByTestId while the DOM still shows "Loading Gantt chart…" — first merge-queue casualty 15 minutes after an identical-content pass

[zhuangjianguo]

Filed by the objectstack skills-lane PM seat (session session_01EXxTW8mvPBhoHxmyPZ63de) while root-causing a merge-queue dequeue. Recording + routing only — plugin-gantt is not this lane's surface; the owning lane grades.

The nondeterminism, measured

run	queue branch	CI verdict	time (2026-08-31)
33352366338	gh-readonly-queue/main/pr-6936-b03ba3ad	success	02:59Z
33352591198	gh-readonly-queue/main/pr-6908-b84dc185	failure — this test, alone (1 of 6,393)	03:15Z

The test file is byte-identical in both trees (born on main at e3d117a, PR #6922, 2026-08-30T18:38Z; unchanged since). The two queue trees differ from each other only by #6936 (a types-authority change) and #6908 (hooks + AGENTS.md + a workflow matrix + one word in a gate script — zero runtime code, zero vitest files, nothing in plugin-gantt). A pass/fail split on materially identical content is nondeterminism inside the test.

The failure, verbatim shape

Test (shard 4/4), job 99368684855: TestingLibraryElementError: Unable to find an element by: [data-testid="gantt-view"] at ObjectGantt.referenceArms-6837.test.tsx:257, in case "refusal — one named case for the deleted key › and degrades to the distinct loaded values rather than rendering nothing". The rendered DOM at query time is the component's loading state (Loading Gantt chart...).

:256 is const { ds, view } = await mount(FIELD_DEFS.legacy_camel); and :257 immediately issues a synchronous view.getByTestId('gantt-view') — a sync query racing the component's async load. The component behaved correctly (it rendered its loading state); the test assumes render completion that mount does not guarantee.

Mechanism hypothesis (owner verifies before relying)

Replace the sync getByTestId('gantt-view') at the top of that case with await view.findByTestId('gantt-view') (or whatever load barrier the file's other cases use — they pass consistently, so a working pattern likely exists a few lines away). The fix belongs in the test; no component change is indicated by this evidence.

Why it matters

It sits in the required CI suite, so every merge-queue entry is exposed: it has already dequeued one green, approved PR (#6908, CI_FAILURE, 03:16Z). A racy required test taxes the whole queue, and the queue is where it will keep firing — queue runs are exactly the runs that re-execute it on fresh trees all day.

Handling on the casualty side: #6908 was re-queued once as the single legitimate re-run; a second failure on the same test re-confirms this finding and should raise its priority.

Refs: #6922 (where the test landed) · #6837 (the behavior it pins) · #6908 (the dequeued PR; standing-down comment there mirrors this evidence).

Generated by Claude Code

[zhuangjianguo]

Re-run datapoint: after the single re-queue, the second merge-queue run passed and #6908 merged at 03:42Z — the failure did not reproduce. That is the third observation on this test in under an hour (pass 02:59Z · fail 03:15Z · pass ~03:40Z, materially identical content each time), which strengthens the nondeterminism reading: the race is real but intermittent, so it will keep taxing the queue at random rather than blocking it outright. The casualty PR is resolved; this card remains the fix carrier for the test itself.

---

Generated by Claude Code