Failing test: Chrome UI Functional Tests.src/platform/test/functional/apps/dashboard/group5/dashboard_query_bar·ts - dashboard app - group 5 dashboard query bar causes panels to reload when refresh is clicked #296947

Activity

1. kibanamachine

   added

   failed-testA test failure on a tracked branch, potentially flaky-testA test failure on a tracked branch, potentially flaky-test

   on Oct 10, 2026
2. botelastic

   added

   needs-teamIssues missing a team labelIssues missing a team label

   on Oct 10, 2026
3. kibanamachine

   added

   Team:DashboardsTeam for Dashboard, Lens, elastic-charts, Controls, legacy editors and Canvas t//Team for Dashboard, Lens, elastic-charts, Controls, legacy editors and Canvas t//

   on Oct 10, 2026
4. infra-vault-gh-plugin-prod commented on Oct 10, 2026

   

   infra-vault-gh-plugin-prodbot

   on Oct 10, 2026

   Contributor

   More actions

   Pinging @elastic/kibana-dashboards (Team:Dashboards)
5. botelastic

   removed

   needs-teamIssues missing a team labelIssues missing a team label

   on Oct 10, 2026
6. github-actions commented on Oct 10, 2026

   

   github-actionsbot

   on Oct 10, 2026 – with GitHub Actions

   Contributor

   More actions

   Test needs an update — a 5s retry budget consumed by a 10s read

   pieChart.expectEmptyPieChart() got exactly one zero-timeout existence poll, fired 10s after the submit click and already past the tryForTime(5000) deadline; the element it waits for appeared ~1s later.

   Details

   Proposed fix

   Give each awaited signal one bounded wait of its own instead of a too-small retry budget wrapped around two expensive reads (Wait for UI updates after actions):

   file:line	change
   services/visualizations/pie_chart.ts:201-204	Replace the zero-timeout testSubjects.exists(...) + expect with a single bounded wait that owns the signal: await this.testSubjects.existOrFail('partitionVisEmptyValues');
   apps/dashboard/group5/dashboard_query_bar.ts:48-52	Drop the retry.tryForTime(5000) wrapper. Replace discover.getColumnHeaders() (a negative read that costs a full 10s) with a positive wait on the saved-search panel's own empty-state signal — await find.byCssSelector('[data-test-subj="embeddedSavedSearchDocTable"] [data-document-number="0"]') — then await pieChart.expectEmptyPieChart(). Drop the now-unused retry and discover handles.

   [data-document-number="0"] is rendered by the unified data table's empty branch (data_table.tsx:1573-1581) and is present in the saved DOM snapshot, so both waits target verified signals.

   Note the blast radius: expectEmptyPieChart has 8 call sites across the dashboard and controls suites. Making it wait is strictly more tolerant than failing instantly, but the change should get a flaky-runner pass over dashboard/group2, group3, group4, group5 and dashboard_elements/controls rather than this spec alone.

   Root cause & evidence

   The 5s budget cannot cover the work inside it, and the pie-chart assertion does not wait at all. From the failing job log (open Artifacts for the screenshot and DOM snapshot):

   • 00:07:36 — querySubmitButton clicked; tryForTime(5000) deadline is now 00:07:41.
   • 00:07:36 — attempt #0 dies immediately on stale element reference (the dashboard was mid re-render), burning one of only two attempts.
   • 00:07:36 → 00:07:46 — attempt links to styles and js #1 spends 10s inside discover.getColumnHeaders(). That resolves to find.allByCssSelector('.euiDataGridHeaderCell__content'), which sets the WebDriver implicit wait to timeouts.find (10s) before findElements — so its success case (no grid ⇒ []) can only be reached after the full 10s expires. Asserting the grid's absence this way is inherently twice the enclosing budget.
   • 00:07:46 — expectEmptyPieChart() finally runs. testSubjects.exists is a one-shot existsByDisplayedByCssSelector(..., 0) — the log shows timeout=0 — so it gets a single poll, returns false, and the blown deadline means there is no attempt Change of links to styles and js #2.
   • 00:07:47 — the DOM snapshot taken 1s later contains data-test-subj="partitionVisEmptyValues" on a panel marked data-render-complete="true", and the screenshot shows both panels at "No results found".

   So the awaited state was reachable and simply rendered after the test stopped looking.

   Additional context

   • Ruled out: not a product bug — no Kibana ERROR/WARN and no browser[SEVERE] entries between the click (00:07:36) and the failure (00:07:47), and both panels' empty states are in the captured DOM. Not shared-state or environment either: the FIPS agent is merely slow, which is exactly what a correct bounded wait absorbs.
   • Verification: node scripts/functional_tests --config src/platform/test/functional/apps/dashboard/group5/config.ts

   Tip

   Marked "AI-fixable". Add ai:fix-flaky to request a fix now; otherwise it will be requested automatically if the test fails again.

   Generated by Failed Test Investigator for #296947 · claude · opus · 455 AIC · ⌖ 39.1 AIC · ⊞ 14.1K · ◷
7. kibanamachine

   added

   failure:ai-fixableFailed test investigator: a fix is available and a PR can be openedFailed test investigator: a fix is available and a PR can be opened

   failure:test-needs-updateFailed test investigator: failure lives in the test codeFailed test investigator: failure lives in the test code

   on Oct 10, 2026