[Search Sessions] Client side search cache

[lizozom]

Summary

Depends on #95688 and #95774

This PR introduces client side caching for search requests, saving unnecessary server round trips and ES workload.
This type of caching is sessionId based, so that identical searches will be executed at most once within a single search session.

Here are some examples when this may comes in handy:

• Lens may generate identical queries, when rendering different chart types with the same underlying data
• Lens may also generate identical queries when the user changes a parameters like color or legend format
• Dashboard may fire identical requests from multiple embeddables.

Cache management and eviction

The new search response cache uses a hash of the query as a key. For each key, it stores a search observable (which are now concluded with a shareReplay operation to avoid repeated execution) and a search abort controller (which is used to coordinate the cancellation of a search, when all consumers abort it).

The cache size is limited by the amount and by the total response size of cached items. Once one of those are hit, the cache is shrinked based on LRU. Individual items that are bigger than the maximum response are not cached from the get go.

If a search observable resolves with an error, the error is passed on to any existing subscribers, and then its evicted from the cache.

Testing

• Added functional test which will be enabled in [Search] enable fun-ctional tests #97398
• x-pack/plugins/data_enhanced/public/search/search_abort_controller.test.ts
  • Changed SearchAbortController constructor
• x-pack/plugins/data_enhanced/public/search/search_response_cache.test.ts
  • 'clear evicts all'
  • 'evicts searches that threw an exception'
  • 'evicts searches that returned an error response'
  • 'evicts oldest item if has too many cached items'
  • 'evicts oldest item if cache gets bigger than max size'
  • 'evicts from cache any single item that gets bigger than max size'
  • 'get updates the insertion time of an item'
  • 'caches a response and re-emits it'
  • 'cached$ should emit same as original search$'
  • 'cached$ should emit only current value and keep emitting if subscribed while search$ is running'
  • 'cached$ should emit only last value if subscribed after search$ was complete'
• x-pack/plugins/data_enhanced/public/search/search_interceptor.test.ts
  • 'should be disabled if there is no session'
  • 'should fetch different requests in a single session'
  • 'should track searches that come from cache'
  • 'should cache partial responses'
  • 'should not cache error responses'
  • 'should deliver error to all replays'
  • 'should ignore anything outside params when hashing'
  • 'should ignore preference when hashing'
  • 'should return from cache for identical requests in the same session'
  • 'aborting a search that didnt get any response should retrigger search'
  • 'aborting a running first search shouldnt clear cache'
  • 'aborting a running first search shouldnt clear cache'
  • 'aborting both requests should cancel underlaying search only once'
  • 'aborting both searches should stop searching and clear cache'
  • 'aborting a completed search shouldnt effect cache'

Release Note

Introduces client side, search session based, caching.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[Dosant]

Recent changes LGTM.

I am still wondering about this thread (About tying this feature to sessions, which seem not related) and not sure if we should leave this as-is:
https://github.com/elastic/kibana/pull/92439/files?file-filters%5B%5D=.ts&file-filters%5B%5D=.tsx#r601345261

We probably should jump on a call and chat. I understand that we might want to merge as is to deliver this to Lens and follow-up if needed later.

[flash1293]

I understand that we might want to merge as is to deliver this to Lens and follow-up if needed later.

Makes sense to me - happy to revisit this on the Lens side later one if we decide to change the way the cache is cleared. Right now it's necessary like this because otherwise the "Refresh" button won't work if there is no session id (it will try to send a new request, but it will just hit the cache)

[Dosant]

Discussed tying caching to sessionId offline and agreed that we can revisit when there is a use-case of caching without sessions.

Also agreed to make an e2e caching test inside example plugin with custom search strategy

[ppisljar]

LGTM, tested on chrome linux

[kibanamachine]

💚 Backport successful

Status	Branch	Result
✅	7.x

This backport PR will be merged automatically after passing CI.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 869e0c7
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
dataEnhanced	98	104	+6

Async chunks

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

id	before	after	diff
lens	943.7KB	943.8KB	+51.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	788.7KB	788.9KB	+193.0B
dataEnhanced	24.7KB	35.1KB	+10.4KB
total			+10.6KB

Unknown metric groups

API count

id	before	after	diff
data	3436	3438	+2

API count missing comments

id	before	after	diff
data	2944	2946	+2

History

• 💛 Build #120304 was flaky 869e0c7
• 💔 Build #120038 failed b9a82c5
• 💔 Build #119585 failed 15cf1e0
• 💚 Build #119165 succeeded bdc3c9a
• 💛 Build #118723 was flaky a8efa69

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

cc @lizozom

[elasticmachine]

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