wiki BrowseTab tests flake under full-suite load by clicking Save before the note editor settles

[atomantic]

Problem

client/src/components/wiki/tabs/BrowseTab.test.jsx fails intermittently in a full cd client && npm test run and passes every time in isolation. Observed once in a run of 832 files (1 failed | 830 passed), then green on an immediate re-run of the identical tree.

The failure is a Testing Library "unable to find an element" throw out of the suite's own helper, which queries the Save control the moment the tab mounts:

const clickSave = async () => {
  const before = api.updateNote.mock.calls.length;
  fireEvent.click(screen.getByRole('button', { name: /Save/ }));   // <- throws here
  await waitFor(() => expect(api.updateNote.mock.calls.length).toBe(before + 1));
};

getByRole is synchronous, so under contention (the client suite runs two jsdom workers) the click happens before the editor has finished mounting and the button exists. The dumped DOM in the failure shows the surrounding icon markup rendered but not the control the query wants.

This is the same class as #5857 (ChiefOfStaff page tests flake under full-suite load by querying an unsettled page mount), but a different file — that issue names only the ChiefOfStaff suite, so this one is not covered by it.

Work

Make the helper wait for the control instead of assuming it is present: await screen.findByRole('button', { name: /Save/ }) before the fireEvent.click, and give any other synchronous first-query in the file the same treatment. Do not paper over it with a bare timeout.

While in the file, check whether the mount that precedes clickSave is itself awaited — an unawaited render is the usual upstream cause, and fixing it there is better than making each query async.

Acceptance criteria

• No synchronous getBy* query in BrowseTab.test.jsx runs against a mount that has not settled.
• The suite still passes in isolation and in a full cd client && npm test.
• Assertions are otherwise unchanged — this is a flake fix, not a rewrite.

Files

• client/src/components/wiki/tabs/BrowseTab.test.jsx

[Bryandero98]

I'd like to work on this — could you assign it to me?

[Bryandero98]

Fixed and merged in #6109.

[atomantic]

Already delivered on main — closing.

Evidence: commit ce46386ca — "test: fix flaky BrowseTab Save-button query racing the Edit transition (#6051)", currently the tip commit touching client/src/components/wiki/.

It implements exactly the fix this issue asked for in client/src/components/wiki/tabs/BrowseTab.test.jsx:

• clickSave() now does fireEvent.click(await screen.findByRole('button', { name: /Save/ })) instead of the synchronous getByRole.
• openEditor() additionally awaits findByRole('button', { name: /Save/ }) after clicking Edit, so the Save/Cancel row is settled once rather than re-awaited at every clickSave() call site.

No arbitrary timeout was introduced, and no assertion was weakened.

Acceptance criteria check:

• No synchronous getBy* runs against an unsettled mount — confirmed. Every remaining getBy*/queryBy* in the file either follows the synchronous initial renderTab() (the note list renders from props, no async load) or sits after an awaited findBy*/waitFor. The getByRole('button', { name: 'Cancel' }) click is safe because Cancel mounts in the same row as the already-awaited Save anyway.
• Still passes in isolation — verified locally: 8 tests passing, and green across 9 consecutive runs of the file.
• Assertions otherwise unchanged — the diff is 6 added / 1 removed lines, all synchronization.