Skip to content
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] Search Sessions with relative time range #84405

Merged
merged 13 commits into from
Jan 12, 2021

Conversation

Dosant
Copy link
Contributor

@Dosant Dosant commented Nov 26, 2020

Summary

Part of #83640

In master background session restoration works only for absolute time ranges.
This pr attempts to make it work for relative time ranges, by "syncing" Date.now() between different searches when relative time range is converted into absolute time range.

Relative to absolute time conversion is not centralized even though we already had some forceNow logic for reporting. So some conversions could be missed and I am happy to follow on that

NowProvider is introduced in data services which keeps tracked of current now value. When session is started sessionService sets a new now into NowProvider so all subsequent searches using it for converting from relative to absolute time range:

high-level diagram

Untitled-2020-12-07-1233-3

In future instead of using now for converting just time filter we would explore using point at time api

There was an edge case with auto refresh. Previously new session wasn't created on auto refresh fetches and with new approach it would cause the same now for all refreshes. Now new sessions are created on auto refresh fetches. For this autoRefresh subscription was moved on a dashboard level and removed from embeddable layer. #84405

How to test

xpack.data_enhanced.search.sendToBackground.enabled: true
data.search.aggs.shardDelay.enabled: true # helpful to create "slow" visualizations
  1. Create a dashboard with search, visualize and lens embeddable.
  2. Make a search with relative time range. Save it.
  3. Get searchSessionId from any of inspector. Get absolute time range from any of inspectors.
  4. build a dashboard URL to restore a session: ${dashboardURL}&searchSessionId=${searchSessionId} and replace relative time range with copied time range
  5. Open it. Search session should be restored and you should see absolute time range

^^ this is what functional test doest

Demo

I took this pr + #81707 to record this demo:

demo_720.mov

Use this branch to try it yourself: https:/Dosant/kibana/tree/feature/data/management-ui-plus

Checklist

For maintainers

@Dosant Dosant force-pushed the dev/search/relative-timerange branch from 42fd29a to a13e3ce Compare December 2, 2020 14:15
@Dosant Dosant changed the title [WIP][Search] Send to background with relative time range [Feedback wanted][Search] Send to background with relative time range Dec 2, 2020
@Dosant Dosant added Feature:Search Querying infrastructure in Kibana Team:AppServices labels Dec 2, 2020
@Dosant Dosant requested review from lukasolson, lizozom, tsullivan and ppisljar and removed request for lukasolson December 2, 2020 18:01
@Dosant
Copy link
Contributor Author

Dosant commented Dec 3, 2020

@elasticmachine merge upstream

Copy link
Member

@lukasolson lukasolson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't tested yet, but the approach seems good to me. I would like to hear from @lizozom and/or @ppisljar since they've been closer to this code.

src/plugins/data/public/search/session/session_service.ts Outdated Show resolved Hide resolved
/**
* Used to synchronize time between parallel searches with relative time range that rely on `now`.
*/
export class NowProvider {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am wondering why is this not part of session service ? i would expect that when creating a session its 'fixed in time' by converting the relative time to absolute.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not part of session service because it is also includes functionality the previously was part of time filter about getting now from the URL (so not only session can control "now"):
https:/elastic/kibana/pull/84405/files/c92374a20f65fe24447bdef8c5b1dbf8c94dfeec#diff-fe41d6d47fbb6465cde6d519ae701f58b0259c89ecf3779048a49651a43b6276R29

import { parse } from 'query-string';

/** @internal */
export function parseQueryString() {
export function getForceNowFromUrl(): Date | undefined {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this moved from timefilter to this new nowProvider
Long term we should make apps responsible for getting this from the URL and setting it into nowProvider

@Dosant Dosant added release_note:skip Skip the PR/issue when compiling release notes v7.12.0 v8.0.0 labels Dec 9, 2020
@Dosant Dosant changed the title [Feedback wanted][Search] Send to background with relative time range [Search] Send to background with relative time range Dec 9, 2020
@Dosant Dosant marked this pull request as ready for review December 9, 2020 17:21
@Dosant Dosant requested a review from a team December 9, 2020 17:21
@Dosant Dosant requested review from a team as code owners December 9, 2020 17:21
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-services (Team:AppServices)

@Dosant
Copy link
Contributor Author

Dosant commented Dec 10, 2020

@elasticmachine merge upstream

Copy link
Member

@tsullivan tsullivan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not vastly familiar with the code that is changed in this PR. My takeaway is the motivation seems to add a new contract called NowProvider.

we already had some forceNow logic for reporting. So some conversions could be missed and I am happy to follow on that

I'm not sure what you mean by "conversions could be missed". [1]

Can you add more info about what NowProvider is and how an app should use it? Also talk about what conversions you worked on in this PR to help clarify my understanding about [1].

@Dosant Dosant requested a review from a team as a code owner January 4, 2021 18:58
@Dosant Dosant force-pushed the dev/search/relative-timerange branch from 923baf9 to 05b927f Compare January 5, 2021 11:59
@lizozom lizozom changed the title [Search] Send to background with relative time range [Search] Search Sessions with relative time range Jan 6, 2021
Copy link
Contributor

@lizozom lizozom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the code thoroughly and tested the things I could think.
LGTM.

…lative-timerange

# Conflicts:
#	src/plugins/data/public/public.api.md
#	src/plugins/data/public/search/session/search_session_state.ts
#	src/plugins/data/public/search/session/session_service.test.ts
Copy link
Contributor

@ThomThomson ThomThomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review only: Presentation team changes LGTM. Can't wait to see these changes in by default!

@@ -169,6 +169,11 @@ export function DashboardApp({
setLastReloadTime(() => new Date().getTime());
})
);
subscriptions.add(
data.query.timefilter.timefilter.getAutoRefreshFetch$().subscribe(() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: We already have a shortcut const for timefilter declared above. It also might be a bit cleaner to merge the two subs that do the same thing:

subscriptions.add(
  merge(data.search.session.onRefresh$, timeFilter.getAutoRefreshFetch$()).subscribe(() =>
    setLastReloadTime(() => new Date().getTime())
    )
);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improved 👍

@lizozom
Copy link
Contributor

lizozom commented Jan 11, 2021

@elasticmachine merge upstream

@Dosant
Copy link
Contributor Author

Dosant commented Jan 12, 2021

@elasticmachine merge upstream

Copy link
Contributor

@stratoula stratoula left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kibana app code review changes LGTM.

@Dosant
Copy link
Contributor Author

Dosant commented Jan 12, 2021

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
data 612 614 +2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
dashboard 199.9KB 200.1KB +172.0B
data 271.0KB 271.0KB +1.0B
discover 502.2KB 502.0KB -175.0B
lens 1.1MB 1.1MB -224.0B
visualize 131.7KB 132.0KB +325.0B
total +99.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
data 1003.8KB 1006.0KB +2.2KB
visualizations 171.2KB 171.0KB -236.0B
total +2.0KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Search Querying infrastructure in Kibana release_note:skip Skip the PR/issue when compiling release notes v7.12.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants