[Dashboard] Fix search session restoration bug#239822
Merged
Heenawter merged 7 commits intoelastic:mainfrom Oct 22, 2025
Merged
[Dashboard] Fix search session restoration bug#239822Heenawter merged 7 commits intoelastic:mainfrom
Heenawter merged 7 commits intoelastic:mainfrom
Conversation
20a5fa1 to
8a87017
Compare
Contributor
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
Contributor
💛 Build succeeded, but was flaky
Failed CI Steps
Metrics [docs]Async chunks
History
cc @Heenawter |
ThomThomson
approved these changes
Oct 22, 2025
Contributor
ThomThomson
left a comment
There was a problem hiding this comment.
Changes LGTM! Glad to see a usage of isFetchPaused$. Thank you for fixing this.
Contributor
|
Starting backport for target branches: 9.1, 9.2 |
kibanamachine
added a commit
to kibanamachine/kibana
that referenced
this pull request
Oct 22, 2025
Part of elastic#239610 ## Summary Previously, we were **never** hitting the search session cache for dashboards with controls because we were removing the search session ID from the URL and generating a new session once controls published their filters, which lead us to fetch the **new** ID rather than the saved one: <img width="1814" height="1061" alt="SearchSessionMismatch" src="https://github.com/user-attachments/assets/bd7f0f62-99c9-4537-ac56-863162f5e0fb" /> > [!NOTE] > Notice in the above network request that `isRestore` is false, which shows that we are not restoring an existing search session (`dd41248d-3dd7-41e6-99f0-e30c6b4a87f1`); instead; we are fetching from the newly generated one (`1f48aacc-90c5-4081-8157-b9b6d77b33b4`). This was because we weren't awaiting the dashboard controls to publish their filters, which caused `newSession$` to emit prematurely and triggered removing the search session ID from the URL before the search session actually had a chance to be restored. Now, we avoid generating a new search session ID until **after** controls have published their filters. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 5b0b2dc)
Contributor
💔 Some backports could not be created
Note: Successful backport PRs will be merged automatically after passing CI. Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
3 tasks
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
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.
Part of #239610
Summary
Previously, we were never hitting the search session cache for dashboards with controls because we were removing the search session ID from the URL and generating a new session once controls published their filters, which lead us to fetch the new ID rather than the saved one:
Note
Notice in the above network request that
isRestoreis false, which shows that we are not restoring an existing search session (dd41248d-3dd7-41e6-99f0-e30c6b4a87f1); instead; we are fetching from the newly generated one (1f48aacc-90c5-4081-8157-b9b6d77b33b4).This was because we weren't awaiting the dashboard controls to publish their filters, which caused
newSession$to emit prematurely and triggered removing the search session ID from the URL before the search session actually had a chance to be restored. Now, we avoid generating a new search session ID until after controls have published their filters.Checklist
release_note:breakinglabel should be applied in these situations.release_note:*label is applied per the guidelinesbackport:*labels.