[Search] Memory leaks caused by AbortController

[Dosant]

While digging into search code noticed potential improvements around requests cancelation:

1. When firing search requests we subscribe to abort signal

abort.signal.addEventListener('abort', () => {
cancel()
}) 

But it could happen that client already asked to abort request and it seems to handle that case we have to handle it separately:

e.g.:

const { abortSignal = null } = requestOptionsMap.get(request) || {};
if (abortSignal) {
  if (abortSignal.aborted) {
    abort();
  } else {
    abortSignal.addEventListener('abort', abort);
  }
}

Such scenario happened to me in dashboard.

2. I guess that every time we manually subscribe to abort event, we have to unsubscribe also? otherwise it is a memory leak. abortSignal.addEventListener('abort', abort);. note: RxJS fromEvent handle unsubscribe when we unsubscribe from observable.

To confirm this is needed, for example, fetch polyfill does this: https://github.com/github/fetch/blob/master/fetch.js#L534

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[Dosant]

Please note:
removing even listener inside 'abort' event callback won't be enough to fix memory leak issue.
Event listener also should be removed when request finishes: see

[Dosant]

While I was looking into #79498 I noticed that this memory leak issue is more significant than it could have seemed. (this issue is not related to #79498)

Every single search slowly leaks memory because of AbortController usage.

Most of leaks are a closure leak from abort utils

This is what I saw for a dashboard with a bunch of panels with a frequent refresh interval open for couple minutes:

• '>8500 AbortSignals left in memory
• '>3263 AbortControllers left in memory

In general they retained 43mb in memory
This grows with every single search request, so I imagine this could crash large Kibana dashboards with frequent refresh intervals opened for a long time.

@lizozom @lukasolson, I think makes sense to prioritise this and tackle in this cycle.