Flaky CI: un-awaited userEvent calls left across 40 test files after the user-event v14 bump (#43512) #44334

Bug description

#43512 bumped @testing-library/user-event from 12.8.3 to 14.6.5 (merged 2026-09-12) and updated 114 test files for the new API. Some files were missed and still call userEvent without await.

Under v12 these APIs were synchronous, so a bare call was fine. Under v14 every call returns a promise and dispatches its pointer events across delay: 0 timer yields inside RTL's asyncWrapper. When the call is not awaited, the following query or assertion begins while the events are still in flight, so the interaction's dispatch time is charged against the next waitFor/findBy* budget (default 1000 ms). On a loaded CI runner that budget can run out before the UI settles, producing intermittent sharded-jest-tests failures that are unrelated to the change under test.

This is not hypothetical. The same mechanism has already been confirmed twice on master:

• Flaky CI: sharded-jest-tests (4) — ControlPanelsContainer.test.tsx "renders ControlPanelSections" (un-awaited userEvent.click after user-event v14) #44314 — ControlPanelsContainer.test.tsx, Expected length: 5, Received length: 4 (fix: test(explore): await the Customize tab click in ControlPanelsContainer test #44315)
• Flaky CI: sharded-jest-tests — useExploreAdditionalActionsMenu.test.tsx "Export All Data" submenu (un-awaited userEvent calls after user-event v14) #44322 — useExploreAdditionalActionsMenu.test.tsx, Unable to find an element with the text: Export All Data (fix: test(explore): await userEvent calls in useExploreAdditionalActionsMenu test #44323)

A repo-wide scan using the TypeScript compiler API — matching userEvent.<method>(...) used as an expression statement, not already awaited — finds 140 remaining un-awaited calls across 40 test files. Of those, 133 across 39 files sit directly inside an async function and need nothing more than a mechanical await.

The largest concentrations:

The remaining 7 call sites are not inside an async function and need restructuring rather than a mechanical await: two sit inside a waitFor callback (src/pages/Home/Home.test.tsx, src/features/datasets/AddDataset/Footer/Footer.test.tsx), one is in a synchronous helper whose signature would have to change (src/SqlLab/components/SqlEditorTabHeader/SqlEditorTabHeader.test.tsx), and four are in synchronous test() callbacks where awaiting would change what the assertion actually verifies (src/components/RowCountLabel/RowCountLabel.test.tsx). Those are worth handling separately so the behaviour change gets reviewed on its own.

A PR applying the 133 mechanical awaits is ready and will be linked to this issue.

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

N/A (frontend tests)

Node version

18 or greater (CI: 24.16.0)

Browser

Not applicable

Additional context

Each individual file is only a latent flake until CI load happens to exceed the budget, which is why these surface one at a time and look unrelated to each other. Fixing them as a group avoids rediscovering the same root cause file by file.

Precedent for this class of fix: #35918, #35993, #44315, #44323.

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.