Attempt to solve timeout issue when loading legacy visualizations dashboard#271948
Merged
Conversation
maryam-saeidi
added
release_note:skip
maryam-saeidi
added
the
Team:Visualizations
Member
Author
|
/flaky ftrConfig:x-pack/platform/test/functional/apps/lens/open_in_lens/dashboard/config.ts:10 |
Contributor
Flaky Test Runner✅ Build triggered - kibana-flaky-test-suite-runner#12515
|
Contributor
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#12515[✅] x-pack/platform/test/functional/apps/lens/open_in_lens/dashboard/config.ts: 10/10 tests passed. |
Member
Author
|
/flaky ftrConfig:x-pack/platform/test/functional/apps/lens/open_in_lens/dashboard/config.ts:50 |
Contributor
Flaky Test Runner✅ Build triggered - kibana-flaky-test-suite-runner#12516
|
maryam-saeidi
added
v9.4.3
backport:version
|
Pinging @elastic/kibana-visualizations (Team:Visualizations) |
Contributor
Flaky Test Runner Stats🎉 All tests passed! - kibana-flaky-test-suite-runner#12516[✅] x-pack/platform/test/functional/apps/lens/open_in_lens/dashboard/config.ts: 50/50 tests passed. |
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]
|
Contributor
|
Starting backport for target branches: 9.4 |
Contributor
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added a commit
that referenced
this pull request
May 29, 2026
…ns dashboard (#271948) (#271986) # Backport This will backport the following commits from `main` to `9.4`: - [Attempt to solve timeout issue when loading legacy visualizations dashboard (#271948)](#271948) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Maryam Saeidi","email":"maryam.saeidi@elastic.co"},"sourceCommit":{"committedDate":"2026-05-29T19:09:56Z","message":"Attempt to solve timeout issue when loading legacy visualizations dashboard (#271948)\n\nCloses https://github.com/elastic/kibana/issues/271816\n\n## Summary\n\n### Theory\n\n[#271520](#271520) exposed the\nissue because it changed the timing of FTR’s first authenticated\nnavigation.\n\nBefore that PR, common.navigateToApp('dashboards') hit the login page,\nfilled the UI form, waited for Kibana chrome, then navigated to the app\nURL again. That slower, multi-step flow gave the Dashboards app more\ntime to settle on #/list before the next call to\nloadDashboardInEditMode().\n\nAfter that PR, login is done by API and cookie injection.\nloginIfPrompted() now injects the sid cookie and navigates directly to\nthe target app URL. That is faster and skips some of the old UI-login\nwaits. So the test reaches:\n\n```\ndashboard.initTests() -> dashboard.loadDashboardInEditMode() -> gotoDashboardLandingPage()\n```\n\nsooner, while the Dashboards route can still be settling.\n\nThe underlying bug was already in gotoDashboardLandingPage(): it checks\nthe URL once, and if it does not see dashboards#/list at that exact\nmoment, it assumes it must be inside a dashboard and waits for the\nin-dashboard breadcrumb.","sha":"5ed988c106ac137cb6898f98eb53c7be52a6d014","branchLabelMapping":{"^v9.5.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Visualizations","release_note:skip","backport:version","v9.5.0","v9.4.3"],"title":"Attempt to solve timeout issue when loading legacy visualizations dashboard","number":271948,"url":"https://github.com/elastic/kibana/pull/271948","mergeCommit":{"message":"Attempt to solve timeout issue when loading legacy visualizations dashboard (#271948)\n\nCloses https://github.com/elastic/kibana/issues/271816\n\n## Summary\n\n### Theory\n\n[#271520](#271520) exposed the\nissue because it changed the timing of FTR’s first authenticated\nnavigation.\n\nBefore that PR, common.navigateToApp('dashboards') hit the login page,\nfilled the UI form, waited for Kibana chrome, then navigated to the app\nURL again. That slower, multi-step flow gave the Dashboards app more\ntime to settle on #/list before the next call to\nloadDashboardInEditMode().\n\nAfter that PR, login is done by API and cookie injection.\nloginIfPrompted() now injects the sid cookie and navigates directly to\nthe target app URL. That is faster and skips some of the old UI-login\nwaits. So the test reaches:\n\n```\ndashboard.initTests() -> dashboard.loadDashboardInEditMode() -> gotoDashboardLandingPage()\n```\n\nsooner, while the Dashboards route can still be settling.\n\nThe underlying bug was already in gotoDashboardLandingPage(): it checks\nthe URL once, and if it does not see dashboards#/list at that exact\nmoment, it assumes it must be inside a dashboard and waits for the\nin-dashboard breadcrumb.","sha":"5ed988c106ac137cb6898f98eb53c7be52a6d014"}},"sourceBranch":"main","suggestedTargetBranches":["9.4"],"targetPullRequestStates":[{"branch":"main","label":"v9.5.0","branchLabelMappingKey":"^v9.5.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/271948","number":271948,"mergeCommit":{"message":"Attempt to solve timeout issue when loading legacy visualizations dashboard (#271948)\n\nCloses https://github.com/elastic/kibana/issues/271816\n\n## Summary\n\n### Theory\n\n[#271520](#271520) exposed the\nissue because it changed the timing of FTR’s first authenticated\nnavigation.\n\nBefore that PR, common.navigateToApp('dashboards') hit the login page,\nfilled the UI form, waited for Kibana chrome, then navigated to the app\nURL again. That slower, multi-step flow gave the Dashboards app more\ntime to settle on #/list before the next call to\nloadDashboardInEditMode().\n\nAfter that PR, login is done by API and cookie injection.\nloginIfPrompted() now injects the sid cookie and navigates directly to\nthe target app URL. That is faster and skips some of the old UI-login\nwaits. So the test reaches:\n\n```\ndashboard.initTests() -> dashboard.loadDashboardInEditMode() -> gotoDashboardLandingPage()\n```\n\nsooner, while the Dashboards route can still be settling.\n\nThe underlying bug was already in gotoDashboardLandingPage(): it checks\nthe URL once, and if it does not see dashboards#/list at that exact\nmoment, it assumes it must be inside a dashboard and waits for the\nin-dashboard breadcrumb.","sha":"5ed988c106ac137cb6898f98eb53c7be52a6d014"}},{"branch":"9.4","label":"v9.4.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #271816
Summary
Theory
#271520 exposed the issue because it changed the timing of FTR’s first authenticated navigation.
Before that PR, common.navigateToApp('dashboards') hit the login page, filled the UI form, waited for Kibana chrome, then navigated to the app URL again. That slower, multi-step flow gave the Dashboards app more time to settle on #/list before the next call to loadDashboardInEditMode().
After that PR, login is done by API and cookie injection. loginIfPrompted() now injects the sid cookie and navigates directly to the target app URL. That is faster and skips some of the old UI-login waits. So the test reaches:
sooner, while the Dashboards route can still be settling.
The underlying bug was already in gotoDashboardLandingPage(): it checks the URL once, and if it does not see dashboards#/list at that exact moment, it assumes it must be inside a dashboard and waits for the in-dashboard breadcrumb.