SEPURI-SAI-KRISHNA opened a new issue, #44314:
URL: https://github.com/apache/superset/issues/44314
### Bug description
Since `@testing-library/user-event` was bumped from 12.8.3 to 14.x in #43512
(merged 2026-09-12), `sharded-jest-tests (4)` intermittently fails in
`superset-frontend/src/explore/components/ControlPanelsContainer.test.tsx`:
```
● ControlPanelsContainer › renders ControlPanelSections
expect(received).toHaveLength(expected)
Expected length: 5
Received length: 4
```
The four headers received are the Data tab's sections (`GROUP BY`, `NOT
GROUPED BY`, `Query`, and an unlabeled one): the Customize tab's section never
rendered before the assertion gave up.
Failures seen, all on shard 4, all on 2026-09-14:
| Branch | Job |
|---|---|
| `master` |
https://github.com/apache/superset/actions/runs/34872184919/job/104072150381 |
| `feature-canvas-filter` |
https://github.com/apache/superset/actions/runs/34792812860/job/103821930836 |
| `sc-120488-starting-version-row` |
https://github.com/apache/superset/actions/runs/34894590802/job/104146817041 |
That is 3 of roughly 214 Frontend Build CI runs that day, on unrelated
changes.
**Cause.** Line 142 calls `userEvent.click(...)` without `await`:
```tsx
userEvent.click(screen.getByRole('tab', { name: /customize/i }));
await waitFor(() => {
expect(screen.getAllByTestId('collapsible-control-panel-header')).toHaveLength(5);
});
```
Under user-event 12 `click` was synchronous, so this was fine. Under 14
every API call returns a promise and dispatches its pointer events across
`setTimeout` yields (`delay: 0`), wrapped in RTL's `asyncWrapper`. Without the
`await`, `waitFor` starts while the click is still being dispatched, so the
click's own dispatch time is taken out of `waitFor`'s default 1000 ms budget.
Instrumenting the test locally:
| | click resolves | `waitFor` polls |
|---|---|---|
| no `await` (current) | +100 ms, during `waitFor` | 4 |
| `await` | +81 ms, before `waitFor` starts | 1 |
#43512 updated 114 test files for the v14 API but not this one (last touched
in #40229).
### Screenshots/recordings
_No response_
### Superset version
master / latest-dev
### Python version
N/A (frontend test)
### Node version
18 or greater (CI: 24.16.0)
### Browser
Not applicable
### Additional context
I could not force the failure locally: the unmodified test passed 12/12 runs
under full CPU load, and CI shard 4 (`npm run test -- --coverage --shard=4/8`)
passed 3/3 runs pinned to 4 cores. The evidence is the CI history above plus
the timing measurement.
Precedent for the same class of fix: #35918, #35993.
### 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]
