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
What is the bug?
In RollupRunner we don't set cancelAfterTimeInterval parameter on SearchRequest object. Consequence of this is that global cluster setting search.cancel_after_time_interval will override it, which if set too low, could impact rollup run success rate.
How can one reproduce the bug?
Steps to reproduce the behavior:
Set cluster setting search.cancel_after_time_interval to something very low, like 1s
Create rollup job on index with some number of documents/shards
See Cancellation timeout error (TaskCancelledExceptioncancelled exception)
What is the expected behavior?
Rollup job should have full control of this timeout.
The text was updated successfully, but these errors were encountered:
Are you proposing its resolution to be individual plugin's responsibility to set the search.cancel_after_time_interval with max(cluster setting search.cancel_after_time_interval, plugin's default minimum value say 5s) ?
If that's the case, then plugin can override this setting by setting a cancelAfterTimeInterval param in every SearchRequest before calling _search. For rollups and transforms I'd say to give it at least 10m.
What is the bug?
In RollupRunner we don't set cancelAfterTimeInterval parameter on SearchRequest object. Consequence of this is that global cluster setting search.cancel_after_time_interval will override it, which if set too low, could impact rollup run success rate.
How can one reproduce the bug?
Steps to reproduce the behavior:
What is the expected behavior?
Rollup job should have full control of this timeout.
The text was updated successfully, but these errors were encountered: