-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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] Integrate "Send to background" UI with session service #83073
Conversation
💚 Build Succeeded
|
⏳ Build in-progress, with failures
Failed CI StepsHistory
To update your PR or re-run it, just comment with: |
⏳ Build in-progress, with failures
Failed CI StepsHistory
To update your PR or re-run it, just comment with: |
b037743
to
3e102cd
Compare
Pinging @elastic/kibana-app-services (Team:AppServices) |
So when I saved the session, use the id in inspect in the URL, I'm getting an error message: How can I see all the sessions that are available? thx! |
@kertal, Do you search with relative time range? It doesn't work for relative time range just yet (I noted that in pr description). This will be handled separately.
Management UI is not implemented yet, but if needed you could use API (session service) or look for saved objects of type |
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, tested locally in Chrome, Firefox, works 👍 . Tested "restore flow where you saved to background AFTER search is finished". Thx for the refactoring
@elasticmachine merge upstream |
@elasticmachine merge upstream |
public find( | ||
options: SearchSessionFindOptions | ||
): Promise<SavedObjectsFindResponse<BackgroundSessionSavedObjectAttributes>> { | ||
return this.http!.post(`/internal/session`, { |
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
Shouldn't find use http.get
?
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 agree get
makes more sense, especially since core.savedObjectClient
also uses get
But this wasn't aded in this pr so out of scope here. cc @lukasolson
src/plugins/dashboard/public/application/dashboard_app_controller.tsx
Outdated
Show resolved
Hide resolved
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 just realized that when a session is saved, we still cancel it upon navigating away.
Saved sessions should be allowed to run upon refresh / navigating away / etc.
In terms of the UI, I think we have too many spinners running
I also think the tooltip of the indicator needs a slight delay, and generally has some weird behavior about it
@lizozom, thanks for the review:
Great catch ❤️ I added logic to not delete async search in case this search was saved with background session. Unfortunately code to support this doesn't look slick, but it is the most reliable way I could think of.
Something to think about... I'll add it here: #83640
Thanks! I caught it once and was thinking I went crazy. I didn't find a way to reliably reproduce it nor a way to fix it. |
this.deps.session.state$ | ||
.pipe( | ||
skip(1), // ignore any state, we are only interested in transition x -> BackgroundLoading | ||
filter((state) => isCurrentSession() && state === SessionState.BackgroundLoading), |
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.
Same should apply if the session has finished loading.
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.
Why not use sessionService.isStored
instead?
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.
Why not use sessionService.isStored instead?
This is what I initially thought of, but it didn't work for me:
sessionService tracks state of the CURRENT session and at the point when we cancel the search it might be already tracking different session.
Let's assume we have a search that will be aborted because of navigating away.
Consider this scenario:
- Session is created, search is fired
- before we start search,
isStored
is still false - Session is saved,
isStored
becomes true - User navigates away. session is cleared.
- Search gets canceled, we are in
catchError
,sessionService.isStored
is false, because session was cleared. So we don't know if the search that was cancelled was stored or not.
To support this use case using session service we should keep state of older sessions.
Other simpler alternative for this specific use case was to subscribe to state change into backgroundLoading
state and keep that bool flag in closure.
Same should apply if the session has finished loading.
Don't think so, it seems that transition to BackgroundLoading
is what we really interested in, if I am not missing something.
…ana into dev/search-server-session-wip
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Page load bundle
Saved Objects .kibana field count
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.
LGTM
* master: (63 commits) Revert the Revert of "[Alerting] renames Resolved action group to Recovered (elastic#84123)" (elastic#84662) declare kbn/monaco dependency on kbn/i18n explicitly (elastic#84660) Remove unscripted fields from sample data index-pattern saved objects (elastic#84659) [ML] Fix unnecessary trigger of wildcard field type search for ML plugin routes. (elastic#84605) Update create.asciidoc (elastic#84046) [Security Solution][Detections] Fix labels and issue with mandatory fields (elastic#84525) Fix flaky test suite (elastic#84602) [Security Solution] [Detections] Create a 'partial failure' status for rules (elastic#84293) Revert "[Alerting] renames Resolved action group to Recovered (elastic#84123)" Update code-comments describing babel plugins (elastic#84622) [Security Solution] [Cases] Cypress for case connector selector options (elastic#80745) [Discover] Unskip doc table tests (elastic#84564) [Lens] (Accessibility) Improve landmarks in Lens (elastic#84511) [Lens] (Accessibility) Focus mistakenly stops on righthand form (elastic#84519) Return early when parallel install process detected (elastic#84190) [Security Solution][Detections] Support arrays in event fields for Severity/Risk overrides (elastic#83723) [Security Solution][Detections] Fix grammatical error in validation message for threshold field in "Create new rule" -> "Define rule" (elastic#84490) [Fleet] Update agent details page (elastic#84434) adding documentation of use of NODE_EXTRA_CA_CERTS env var (elastic#84578) [Search] Integrate "Send to background" UI with session service (elastic#83073) ...
Summary
Part of #83640
This pr connects #81004 + #81099 making send to background indicator/popover more-or-less functional and we can see how the feature is shaping up.
Notes
There is some TODOs in functional tests. Some units tests are missing. I will continue while it is being reviewed.DONEHow to test
To try a restore flow you can build a restore session URL, by getting sessionId from inspector and appending to the URL:
&searchSessionId=${your-id-from-inspector}
. (See tests)Checklist
For maintainers