While digging into search code noticed potential improvements around requests cancelation:
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.
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
Pinging @elastic/kibana-app-arch (Team:AppArch)
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
While I was looking into https://github.com/elastic/kibana/issues/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:

AbortSignals left in memory 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.
Most helpful comment
While I was looking into https://github.com/elastic/kibana/issues/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:
AbortSignals left in memoryAbortControllers left in memoryIn 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.