You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original install method (e.g. download page, yum, from source, etc.): source
Describe the bug:
Async searches started via the data.search.search() API can be cancelled by passing an AbortSignal. When the AbortSignal is triggered while the search logic is polling the async result, the search is supposed be canceled by issuing a DELETE request to a specific data plugin route:
Whether that DELETE request is actually sent depends on the timing of the abort signalling and the unsubscription from the response observable. If the unsubscription happens too early the error representing the cancellation never reaches the catchError operator. That means that the Kibana server and therefore the Elasticsearch server never learn about the cancellation.
Steps to reproduce:
Start a browser-side async search request with an AbortSignal via data.search.search(), which runs for several polling cycles.
Unsubscribe from the response Observable.
Trigger the AbortSignal.
Observe that the DELETE request to cancel the search on the server side is not sent and the search continues to run.
Expected behavior:
The DELETE request is sent regardless of the order of unsubscription or AbortSignal triggering.
Additional context from a conversation with @lizozom:
This interacts with the background sessions functionality, so care has to be taken not to delete the search too eagerly. Something like the following tapUnsubscribe operator might be used to implement more robust cancellation semantics (if guarded correctly).
Kibana version:
master
as of dbd14adBrowser version: Chromium 87.0.4280.88
Original install method (e.g. download page, yum, from source, etc.): source
Describe the bug:
Async searches started via the
data.search.search()
API can be cancelled by passing anAbortSignal
. When theAbortSignal
is triggered while thesearch
logic is polling the async result, the search is supposed be canceled by issuing aDELETE
request to a specificdata
plugin route:kibana/x-pack/plugins/data_enhanced/public/search/search_interceptor.ts
Lines 89 to 92 in 051bbf0
Whether that
DELETE
request is actually sent depends on the timing of the abort signalling and the unsubscription from the response observable. If the unsubscription happens too early the error representing the cancellation never reaches thecatchError
operator. That means that the Kibana server and therefore the Elasticsearch server never learn about the cancellation.Steps to reproduce:
AbortSignal
viadata.search.search()
, which runs for several polling cycles.Observable
.AbortSignal
.DELETE
request to cancel the search on the server side is not sent and the search continues to run.Expected behavior:
The
DELETE
request is sent regardless of the order of unsubscription orAbortSignal
triggering.Additional context from a conversation with @lizozom:
This interacts with the background sessions functionality, so care has to be taken not to delete the search too eagerly. Something like the following
tapUnsubscribe
operator might be used to implement more robust cancellation semantics (if guarded correctly).The text was updated successfully, but these errors were encountered: