Flaky Preview test: the second scroll-into-view is asserted before the effect that makes it has run #1039

New issue

Closed

opened 2026-10-02 20:45:49 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-10-02 20:45:49 +00:00

Collaborator

Seen

PR #1038 (no frontend change at all) went red on CI / Frontend (shard 2/2), run https://git.rhoving.com/rbrooks/Quest-Board/actions/runs/1801 (job 63083):

FAIL src/pages/table/Preview.test.jsx > Preview > coming into view (#1020) > is brought into view again when a fetched entry arrives and the panel has grown, and then no more
AssertionError: expected "vi.fn()" to be called 2 times, but got 1 times
 ❯ src/pages/table/Preview.test.jsx:197:22

1 failed, 1572 passed.

Cause (read from the code; not reproduced locally)

Preview.jsx brings the panel into view from a passive effect (useEffect(..., [kind, id, drawn])). The test does

expect(await screen.findByText("Blackfen adder")).toBeInTheDocument();
expect(scroll).toHaveBeenCalledTimes(2);

findByText resolves as soon as the text is in the DOM, which is at commit. A passive effect runs some time after the commit, so on a busy runner the synchronous assertion on the next line can run before the second scrollIntoView call. The component is right; the test asserts too early. Same family as #604 and #1036.

Fix

Wait for the thing being asserted: await waitFor(() => expect(scroll).toHaveBeenCalledTimes(2)). Test only, no behaviour change.

## Seen PR #1038 (no frontend change at all) went red on **CI / Frontend (shard 2/2)**, run https://git.rhoving.com/rbrooks/Quest-Board/actions/runs/1801 (job 63083): ``` FAIL src/pages/table/Preview.test.jsx > Preview > coming into view (#1020) > is brought into view again when a fetched entry arrives and the panel has grown, and then no more AssertionError: expected "vi.fn()" to be called 2 times, but got 1 times ❯ src/pages/table/Preview.test.jsx:197:22 ``` 1 failed, 1572 passed. ## Cause (read from the code; not reproduced locally) `Preview.jsx` brings the panel into view from a passive effect (`useEffect(..., [kind, id, drawn])`). The test does ```js expect(await screen.findByText("Blackfen adder")).toBeInTheDocument(); expect(scroll).toHaveBeenCalledTimes(2); ``` `findByText` resolves as soon as the text is in the DOM, which is at commit. A passive effect runs some time after the commit, so on a busy runner the synchronous assertion on the next line can run before the second `scrollIntoView` call. The component is right; the test asserts too early. Same family as #604 and #1036. ## Fix Wait for the thing being asserted: `await waitFor(() => expect(scroll).toHaveBeenCalledTimes(2))`. Test only, no behaviour change.

rbrooks referenced this issue from a commit

2026-10-02 20:46:05 +00:00

The Preview scroll test waits for the call it asserts (#1039)

claude-bot referenced this issue from a pull request that will close it,

2026-10-02 21:37:09 +00:00

The Preview scroll test waits for the call it asserts (#1039) #1041

claude-bot referenced this issue

2026-10-02 22:18:54 +00:00

The Claude Code setup becomes a thin layer over the shared user-level set (#1037) #1038

claude-bot closed this issue

2026-10-02 22:19:04 +00:00

claude-bot referenced this issue from a commit

2026-10-02 22:19:05 +00:00

Merge PR #1041: the Preview scroll test waits for the call it asserts (#1039)

claude-bot commented

2026-10-02 22:19:36 +00:00

Author

Collaborator

Done in PR #1041, merged to main on 2026-10-02 with CI green. The test now waits for the second scrollIntoView call instead of asserting it on the line after the text appears; the component is unchanged.

Before the fix the test failed in three CI runs today (#1038, the re-run of #1034, and #1040), all on a busy runner. Branches opened before this merge need main merged in to pick it up.

Done in PR #1041, merged to main on 2026-10-02 with CI green. The test now waits for the second `scrollIntoView` call instead of asserting it on the line after the text appears; the component is unchanged. Before the fix the test failed in three CI runs today (#1038, the re-run of #1034, and #1040), all on a busy runner. Branches opened before this merge need main merged in to pick it up.

claude-bot referenced this issue

2026-10-02 22:46:20 +00:00

Refresh-on-focus can miss a focus that arrives just as a page finishes loading (flaky Thread test) #1036

claude-bot referenced this issue

2026-10-04 15:27:29 +00:00

Flaky test: AppFrame "choosing a rule opens it in place" does not find its dialog under load #1080