Found while landing objectui#9022 (PR objectui#9157). Not folded in: it shares no file, no import and no surface with that diff — grep -c 'useOpenRecordList|DrillNavigation|openRecordList' over both the panel and its test is 0 on both.
The reading
pnpm exec vitest run packages/app-shell/ packages/react/ on 7ac092df8:
Test Files 1 failed | 760 passed (761)
Tests 1 failed | 7544 passed | 1 skipped (7546)
FAIL |dom| packages/app-shell/src/views/RecordApprovalsPanel.viaOverrideMarker.test.tsx
> RecordApprovalsPanel — via_override marker (objectui#5178)
> marks the override row, and only the override row
TestingLibraryElementError: Unable to find an element by: [data-testid="via-override-chip"]
Re-run alone, on the same tree, same commit: Test Files 1 passed (1) / Tests 6 passed (6), exit 0. So the variable is load, not the code under test.
The mechanism, named
renderPanel settles on the wrong thing. It awaits findByTestId('record-approvals-panel') — the panel SHELL — and the test then asserts getAllByTestId('via-override-chip') synchronously. The chips live on timeline rows built from the stubbed /actions response, which is a SECOND async state landing after the shell has already rendered. Under a saturated transform pipeline that second flush can arrive after the assertion, and the failure renders as "the chip does not exist" rather than "the chip has not arrived yet".
This is the class AGENTS.md already describes under 测试纪律 — an unbounded piece of async work billed against a bounded assertion window — with one twist worth recording: here the await is not missing, it is present and pointed at an element that settles EARLIER than the one being asserted. A reviewer reading the test sees an await and stops looking.
Why it matters beyond one red
The failure direction is the bad one for a marker pin. The first assertion is toHaveLength(1); a run where the rows never arrive would read 0, and a future change that stopped rendering the chip ENTIRELY would fail with the same message this race produces. The two are indistinguishable from the output, so the flake trains readers to re-run rather than to look — which is how a real regression in this marker would get re-run into green.
Direction
Settle on the asserted element, not on its container: await screen.findAllByTestId('via-override-chip') (or a findByText on a row that only exists once the actions land) before the length assertion. The sibling cases in the same file that assert an ABSENCE need the positive settle even more, since an absence assertion is satisfied by a page that has not finished rendering. No production code appears to be involved.
Filed by the domain:ui dev seat while working objectui#9022, session session_01UzHd6hDYatoDn17BuwKxnZ — attribution written as prose on purpose, because an attribution footer block is stripped from issue bodies on creation.
Generated by Claude Code
Found while landing objectui#9022 (PR objectui#9157). Not folded in: it shares no file, no import and no surface with that diff —
grep -c 'useOpenRecordList|DrillNavigation|openRecordList'over both the panel and its test is 0 on both.The reading
pnpm exec vitest run packages/app-shell/ packages/react/on7ac092df8:Re-run alone, on the same tree, same commit:
Test Files 1 passed (1)/Tests 6 passed (6), exit 0. So the variable is load, not the code under test.The mechanism, named
renderPanelsettles on the wrong thing. It awaitsfindByTestId('record-approvals-panel')— the panel SHELL — and the test then assertsgetAllByTestId('via-override-chip')synchronously. The chips live on timeline rows built from the stubbed/actionsresponse, which is a SECOND async state landing after the shell has already rendered. Under a saturated transform pipeline that second flush can arrive after the assertion, and the failure renders as "the chip does not exist" rather than "the chip has not arrived yet".This is the class AGENTS.md already describes under 测试纪律 — an unbounded piece of async work billed against a bounded assertion window — with one twist worth recording: here the await is not missing, it is present and pointed at an element that settles EARLIER than the one being asserted. A reviewer reading the test sees an
awaitand stops looking.Why it matters beyond one red
The failure direction is the bad one for a marker pin. The first assertion is
toHaveLength(1); a run where the rows never arrive would read0, and a future change that stopped rendering the chip ENTIRELY would fail with the same message this race produces. The two are indistinguishable from the output, so the flake trains readers to re-run rather than to look — which is how a real regression in this marker would get re-run into green.Direction
Settle on the asserted element, not on its container:
await screen.findAllByTestId('via-override-chip')(or afindByTexton a row that only exists once the actions land) before the length assertion. The sibling cases in the same file that assert an ABSENCE need the positive settle even more, since an absence assertion is satisfied by a page that has not finished rendering. No production code appears to be involved.Filed by the
domain:uidev seat while working objectui#9022, sessionsession_01UzHd6hDYatoDn17BuwKxnZ— attribution written as prose on purpose, because an attribution footer block is stripped from issue bodies on creation.Generated by Claude Code