[Search] Use session service on a dashboard #81297
Merged
Conversation
This file contains 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
Dosant
changed the title
13 tasks
Dosant
changed the title
Dosant
added
Feature:Search
Dosant
commented
Oct 21, 2020
| @@ -23,7 +26,7 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) { | |||
|
|
|||
| it('delayed should load', async () => { | |||
| await PageObjects.common.navigateToApp('dashboard'); | |||
| await PageObjects.dashboard.gotoDashboardEditMode('Delayed 5s'); | |||
| await PageObjects.dashboard.loadSavedDashboard('Delayed 5s'); | |||
There was a problem hiding this comment.
@lukasolson, I doubt that gotoDashboardEditMode was intentional, so I changed it to loadSavedDashboard
loadSavedDashboard is faster because we don't have to wait for initial load and then for a 2nd load after switching to edit mode.
Dosant
added
the
release_note:skip
This was referenced Oct 22, 2020
Dosant
commented
Oct 26, 2020
| @@ -1109,12 +1111,6 @@ export class DashboardAppController { | |||
| $scope.model.filters = filterManager.getFilters(); | |||
| $scope.model.query = queryStringManager.getQuery(); | |||
| dashboardStateManager.applyFilters($scope.model.query, $scope.model.filters); | |||
| if (dashboardContainer) { | |||
| dashboardContainer.updateInput({ | |||
There was a problem hiding this comment.
This is not needed. After removing all dashboard container updates are handled in single place right now.
Looking forward to this file being refactored.
There was a problem hiding this comment.
I'm in the middle of completely re-doing this file as part of deangularization. It will be a functional component - I may end up pinging you for some input at some point.
There was a problem hiding this comment.
@ThomThomson, that's great news 👍 Will be glad to chime in.
From perspective of this pr important bit is that we are calling dashboardContainer.updateInput in a single place and we assume this is when we want to start a new search session.
1 task
lukasolson
approved these changes
Oct 26, 2020
| @@ -153,6 +153,21 @@ export class RequestsViewComponent extends Component<InspectorViewProps, Request | |||
| </EuiText> | |||
| )} | |||
|
|
|||
| {this.state.request && this.state.request.searchSessionId && ( | |||
There was a problem hiding this comment.
Is this only for the functional tests, or do you think there is value in showing this parameter to the user?
There was a problem hiding this comment.
I think it would also be useful for debugging and support purposes
ThomThomson
approved these changes
Oct 27, 2020
|
@elasticmachine merge upstream |
2 tasks
|
There's something weird going on I think. If I hit the refresh button, the I debugged into the Lens embeddable and for a single hit of refresh, it's calling |
lizozom
reviewed
Oct 29, 2020
| @@ -19,5 +19,6 @@ export declare type EmbeddableInput = { | |||
| timeRange?: TimeRange; | |||
| query?: Query; | |||
| filters?: Filter[]; | |||
| searchSessionId?: string; | |||
There was a problem hiding this comment.
This is a major nit, but do we really want to have the name be so specific?
I think sessions can and will be used for more than search.
There was a problem hiding this comment.
I think sessionId is way too vague for dashboards / embeddable level, but OK on search level.
sessionId on dashboard could mean anything:
- user authentication session
- dashboard page session (created once when user loaded a dashboard)
- dashboard app session (to track drill-downs between dashboards without navigating away from a dashboard app)
- and the search / fetch session.
There was a problem hiding this comment.
Agreed, if this terminology is for using in solutions :)
Thanks for pointing that out. There were two issue I found and fixed, let's see what tests say...
|
lizozom
reviewed
Oct 29, 2020
| @@ -374,6 +374,7 @@ export class VisualizeEmbeddable | |||
| query: this.input.query, | |||
| filters: this.input.filters, | |||
| }, | |||
| searchSessionId: this.input.searchSessionId, | |||
There was a problem hiding this comment.
If we pass in the searchSessionId from the visualize app, would that enable sessions for that app too?
(Not in this PR)
| return searchSessionId; | ||
| }; | ||
|
|
||
| const panel1SessionId1 = await getSearchSessionIdByPanel('Sum of Bytes by Extension'); |
There was a problem hiding this comment.
Would it make sense to add tests to test/plugin_functional/test_suites/data_plugin/session.ts to make sure that sessions are being created once per load \ reload?
It was what uncovered the problematic behaviors in Dashboard in the first place.
There was a problem hiding this comment.
I will take a look 👍
but would like to do it in separate pr,
really want to unblock a bunch of follow up prs with merging this :(
|
@elasticmachine merge upstream |
flash1293
approved these changes
Oct 29, 2020
Dosant
added a commit
to Dosant/kibana
that referenced
this pull request
Oct 29, 2020
Dosant
added a commit
that referenced
this pull request
Oct 30, 2020
This was referenced Dec 2, 2020
lizozom
added
release_note:feature
💔 Build Failed
Failed CI Steps
Test FailuresFirefox UI Functional Tests.test/functional/apps/dashboard/dashboard_save·js.dashboard app using legacy data dashboard save warns on duplicate name for new dashboardStandard OutStack TraceFirefox UI Functional Tests.test/functional/apps/dashboard/index·js.dashboard app using legacy data "after all" hook: unloadLogstash in "using legacy data"Standard OutStack TraceChrome UI Functional Tests.test/functional/apps/visualize/index·ts.visualize app "before all" hook in "visualize app"Standard OutStack Traceand 7 more failures, only showing the first 3. Metrics [docs]
History
To update your PR or re-run it, just comment with: |
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.
Release note
Adds Search Sessions support to Kibana Dashboards
Summary
Follow up on #76889
Prev version of this pr with some comments: #81192
Part of #61738
Next step: restore searchSessionId from the URL: #81489
Some context for reviewers
This is part of client side background search. To save or restore a background search, searches will be grouped under a session. We implemented session creation on every search in discover in #76889. This pr creates a search session on every dashboard container state change and propagates
searchSessionIdto embeddable -> search infrastructure.Implementation notes:
Maps: TODO: probably better done separatelyAnything else?3. Added
sessionIddisplayed in inspector. Used it it in a functional test. I also think it would be useful for debug and support purposes.This is how it looks:
Functional test:
Added a test that checks:
How to test
searchSessionIdchanges on different state changes. You can use inspector.Open questions / edge cases to iterate over later
Next steps
searchSessionIdwith dashboardURL [Search][Discover] Restore searchSessionId from URL #81633Checklist
Delete any items that are not applicable to this PR.