Skip to content

Conversation

@AlexGPlay
Copy link
Contributor

@AlexGPlay AlexGPlay commented Dec 1, 2025

Summary

Closes #230909

Right now after a search has finished we keep polling it every 30 seconds, this was because search sessions allowed to save them after they finished, but with background search that's not the case, so we don't need to poll.

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

  • Unit or functional tests were updated or added to match the most common scenarios
  • The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
  • Review the backport guidelines and apply applicable backport:* labels.

@AlexGPlay AlexGPlay self-assigned this Dec 1, 2025
@AlexGPlay AlexGPlay marked this pull request as ready for review December 1, 2025 15:53
@AlexGPlay AlexGPlay requested review from a team as code owners December 1, 2025 15:53
@AlexGPlay AlexGPlay requested a review from lukasolson December 1, 2025 15:53
@AlexGPlay AlexGPlay added release_note:skip Skip the PR/issue when compiling release notes backport:skip This PR does not require backporting Project:AsyncSearch Background search, partial results, async search services. Team:DataDiscovery Discover, search (data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL. t// Feature:BackgroundSearch Background search feature used in Discover, Dashboard, etc. labels Dec 1, 2025
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

Copy link
Contributor

@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.

I think we still want to poll until all pending search requests are completed, otherwise we can get into a situation like this: A dashboard with two panels, one with a search request that takes 5 seconds, another that takes 10 minutes. The first completes after 5s, but doesn't continue polling. After 1 minute of not polling, this gets cleaned up and so if we send to background afterwards, there will be errors.

In practice this doesn't seem to actually happen (from my tests), and I think it's because ES actually only cleans up completed searches every hour. But I think it's still better to be safe than rely on an undocumented behavior in ES.

What are your thoughts?

@AlexGPlay
Copy link
Contributor Author

I think we still want to poll until all pending search requests are completed, otherwise we can get into a situation like this: A dashboard with two panels, one with a search request that takes 5 seconds, another that takes 10 minutes. The first completes after 5s, but doesn't continue polling. After 1 minute of not polling, this gets cleaned up and so if we send to background afterwards, there will be errors.

In practice this doesn't seem to actually happen (from my tests), and I think it's because ES actually only cleans up completed searches every hour. But I think it's still better to be safe than rely on an undocumented behavior in ES.

What are your thoughts?

that sounds good, i'll update to keep the polling until everything has finished in the search session


const schedulePollSearches = () => {
return timer(KEEP_ALIVE_COMPLETED_SEARCHES_INTERVAL).pipe(
return interval(KEEP_ALIVE_COMPLETED_SEARCHES_INTERVAL).pipe(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

i've changed it from timer + repeat to just use interval

Comment on lines +351 to +352
takeUntil(this.disableSaveAfterSearchesExpire$.pipe(filter((disable) => disable))),
takeUntil(stopOnFinishedState$)
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 is the main change, now on top of the existing behavior we stop when the search session is in a completed status

@AlexGPlay AlexGPlay requested a review from lukasolson December 2, 2025 11:39
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Page load bundle

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

id before after diff
data 441.5KB 441.7KB +198.0B

History

cc @AlexGPlay

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting Feature:BackgroundSearch Background search feature used in Discover, Dashboard, etc. Project:AsyncSearch Background search, partial results, async search services. release_note:skip Skip the PR/issue when compiling release notes Team:DataDiscovery Discover, search (data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL. t//

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Background search] Change polling behavior

3 participants