SEPURI-SAI-KRISHNA opened a new issue, #44334:
URL: https://github.com/apache/superset/issues/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`:
   
   - #44314 — `ControlPanelsContainer.test.tsx`, `Expected length: 5, Received 
length: 4` (fix: #44315)
   - #44322 — `useExploreAdditionalActionsMenu.test.tsx`, `Unable to find an 
element with the text: Export All Data` (fix: #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:
   
   | File | Calls |
   |---|---|
   | 
`src/explore/components/controls/ColorSchemeControl/ColorSchemeControl.test.tsx`
 | 12 |
   | `src/dashboard/components/gridComponents/Markdown/Markdown.test.tsx` | 10 |
   | `src/components/Chart/ChartContextMenu/ChartContextMenu.test.tsx` | 10 |
   | `src/features/home/Menu.test.tsx` | 9 |
   | `src/explore/components/DataTablesPane/test/DataTablesPane.test.tsx` | 9 |
   
   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 `await`s 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
   
   - [x] I have searched Superset docs and Slack and didn't find a solution to 
my problem.
   - [x] I have searched the GitHub issue tracker and didn't find a similar bug 
report.
   - [x] 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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to