-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Search] Fix dashboard embeddables don't refetch on searchSessionId change #84261
[Search] Fix dashboard embeddables don't refetch on searchSessionId change #84261
Conversation
# Conflicts: # src/plugins/discover/public/application/embeddable/search_embeddable.ts
242fcc2
to
b268407
Compare
@@ -245,16 +253,9 @@ export class Embeddable | |||
}; | |||
|
|||
async reload() { | |||
const currentTime = Date.now(); | |||
if (this.externalSearchContext.lastReloadRequestTime !== currentTime) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am either missing something or I think this check didn't make sense, because I'd expect Date.now()
on line above to always return later timestamp that is saved inside lastReloadRequestTime
.
I decided to clean this up, pls let me know if this was actually handling some edge case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was put in place to protect from multiple synchronous reload calls, but I didn't find a case where that's a problem. It's fine from my side.
…shboard-start-session-fix
Pinging @elastic/kibana-app-services (Team:AppServices) |
@elasticmachine merge upstream |
…shboard-start-session-fix
…osant/kibana into dev/search/dashboard-start-session-fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't have a problem at all with the workaround of adding a getUpdated$
observable. Anything that helps standardize how embeddables respond to changes is good in my books.
When testing locally, I verified embeddables only fire one network request on refresh, filter change & time range change. The background sessions indicator is also always present now.
One thing I did notice is that the dashboard is reloaded now on 'cancel' when you choose to discard changes. This wasn't the case before, as nothing is changing that would require a re-fetch. Is this intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested the Lens part and seems to work fine
@@ -245,16 +253,9 @@ export class Embeddable | |||
}; | |||
|
|||
async reload() { | |||
const currentTime = Date.now(); | |||
if (this.externalSearchContext.lastReloadRequestTime !== currentTime) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was put in place to protect from multiple synchronous reload calls, but I didn't find a case where that's a problem. It's fine from my side.
@@ -110,7 +110,9 @@ export class Embeddable | |||
|
|||
this.expressionRenderer = deps.expressionRenderer; | |||
this.initializeSavedVis(initialInput).then(() => this.onContainerStateChanged(initialInput)); | |||
this.subscription = this.getInput$().subscribe((input) => this.onContainerStateChanged(input)); | |||
this.subscription = this.getUpdated$().subscribe(() => | |||
this.onContainerStateChanged(this.input) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Should this.input
be used? There's also this.getInput()
which is used in other places. Not sure whether important, just wanted to point it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this.getInput()
is public and this.input
is protected, so I guess inside the embeddable it is fine to use both
Good catch. If you "discard changes" and there is no change in state keys that cause starting a new session, then no refetch would happen. e.g. when just switching between view -> edit -> (discard) -> view mode. But in general with this change we are triggering a refetch more often then we had before. This fixes following bug @lukasolson pointed out:
I think we have to accept this drawback for now with current session management design :( |
@Dosant there shouldn't be a problem with adding a new request to the current session, in this new panel scenario. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested the following
- Switching to edit mode - doesn't clear session
- Cancel back to view mode - doesn't clear session
- Fullscreen - doesn't clear session
- Delete a panel from a dashboard - doesn't clear session
- Moving a panel and saving - doesn't clear session
- Adding a panel and saving - doesn't clear session
When a sesison is not cleared, it means items are added to the existing session, which I find reasonable.
LGTM
@ThomThomson, would you be OK if I create an issue for this excessive fetches we gonna track and look into improving if/when we add this re-open API @lizozom mentions? ---- edit created: #85293 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With an issue for awareness around the excessive fetches I am good to approve this. Hopefully there will be a fix, but if this is just the way the session service works it's not too bad a change anyway.
@elasticmachine merge upstream |
@kertal, although this got all code owners review, search embeddable still needs a 👀 🙏 |
@Dosant ACK, yes, thx, will have a look today |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Async chunks
Distributable file count
Page load bundle
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM, mainly took a look at the search embeddable and it's fetching behavior, recently fixed a double fetch there, so the good news after testing locally: it fetches when it should, no less, no more 👍
Summary
Part of #83640
Fixes a bug on a dashboard with session indicator, that, for example, when switching from view to edit, session indicator disappears:
Now in master, on any dashboard container state change new search session is started, but inner embeddables "dirty" state checking don't check for sessionId changes, so embeddable don't refetch the data.
Because there is new session and no searches are fired, session indicator gets into "empty" state and is not shown.
This pr makes search, visualize and lens embeddables (only those support
searchSessionId
for now) to check ifsearchSessionId
is changed and if it is, then do refetch.To not trigger data refetch on any dashboard container state change, there is also a new optimization inside dashboard to not create a new session on every state change: https://github.com/elastic/kibana/pull/84261/files#diff-d4d5bed484b46a4b7df6cd2d09b106bd761c956c53df96f8da6e683901475156R636
In an original pr which added
searchSessionId
I initially triggered refetch onsearchSessionId
change, but reverted because of this edge case: #81297 (comment)Basically, when refetch is triggered on
searchSesssionId
hitting refresh caused double fetches for each embeddable:When refresh is hit
lastReloadRequestTime
andsearchSesssionId
were updated, thenonResetInput
updated embeddable input and then called force reload: https://github.com/elastic/kibana/blob/master/src/plugins/embeddable/public/lib/embeddables/embeddable.tsx#L206It caused embeddable to fetch twice: once because of updated input and
searchSesssionId
change and then because of forcereload
To workaround this (not very happy with the workaround, open for better ideas) I introduced
getUpdated$
observable https://github.com/elastic/kibana/pull/84261/files#diff-07c6d43a257e24b0d89b752078b298591b28d74047ddc44a38f35d130958a25dR126 which is different frommerge(getInput$(), getOutput$())
that isThis observable allows for embeddables to first react to force
reload
with the latest input/output and later whengetUpdated$()
is emitted embeddable dirty state checking will prevent running fetch again.How to test
Checklist
Delete any items that are not applicable to this PR.
For maintainers