bikash-barnwal opened a new issue, #43200: URL: https://github.com/apache/superset/issues/43200
### Bug description `playwright/tests/recently-archived/recently-archived.spec.ts:192` — *"shows an empty message and no rows when the search matches nothing"* — fails intermittently on PRs that touch nothing related to the archived list, exhausting all three attempts each time. Observed on two unrelated backend-only PRs (export `Cache-Control` headers, and export filename length): - https://github.com/apache/superset/actions/runs/31837169100/job/94890488734 - https://github.com/apache/superset/actions/runs/31838954287/job/94895098865 - https://github.com/apache/superset/actions/runs/31843231172/job/94908528206 (fresh run after rebasing onto latest master) Meanwhile the same job passes on other PRs from the same base (#43184, #43189, #43179, #43186, #43187). ### Failure ``` Error: expect(locator).toBeVisible() failed locator: getByText('No results match your filter criteria') Timeout: 8000ms Error: element(s) not found Error: expect(locator).toHaveCount(expected) failed Expected: 0 Received: 22 <- and 23 on the retry > 206 | await expect(page.getByTestId('archived-row-restore')).toHaveCount(0); ``` ### Suspected cause The received counts are the point: 22 and 23 rows are still on screen, i.e. the **unfiltered** list. The search did not fail to match — it never ran. ```ts await page.goto('archived/'); await expect(page.getByTestId('archived-list-view')).toBeVisible(); const search = page.getByPlaceholder(/type a value/i); await search.click(); await search.fill(`e2e_nonexistent_${Date.now()}`); await search.press('Enter'); ``` `archived-list-view` becomes visible as soon as the container mounts, which is before the first page of rows has been fetched and the table's filter state is wired up. Typing and pressing Enter in that window can be swallowed, leaving the list unfiltered — and the row count then depends on how many archived items other specs in the shard have created, which is why it varies between 22 and 23. A fix would be to wait for the list to actually settle before searching — e.g. for the first `archived-row-restore` to be visible, or for the list request to resolve — rather than for the container alone. ### How to reproduce Re-run the E2E job on an unrelated PR a few times; it reproduces roughly one run in three in recent history. ### Superset version master / latest-dev ### Additional context I did not send a patch because I have no way to run Playwright against a live Superset here to confirm the fix, and a speculative change to a flaky E2E test is easy to get wrong. Happy to write it if someone with a working E2E environment agrees with the diagnosis. -- 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]
