The claiming status was added to tasks as a way to allow Kibana to fetch the documents that were updates during an update by query operation, given the operation doesn't return the updated tasks. In the mget strategy, we know which documents get successfully updated, so there is no need to update it again from claiming to running.
Here is a prototype I did for mget that bypasses the claiming phase https://github.com/elastic/kibana/pull/182394/commits/1c2308c6fcefc471773351e5636eea65a13e8d59. The task_runner.ts would still need to look at the status of the task before determining if it can return early or if it needs to set the task to running. The mget claim strategy should re-use some code instead of re-defining getRetryDelay.
Definition of Done
[ ] When using the mget strategy, tasks go directly to running status
[ ] mget strategy still searches for claiming tasks in case the previous code running while Kibana shut down was update by query
[ ] Update by query strategy still uses claiming status
The
claiming
status was added to tasks as a way to allow Kibana to fetch the documents that were updates during an update by query operation, given the operation doesn't return the updated tasks. In the mget strategy, we know which documents get successfully updated, so there is no need to update it again from claiming to running.Here is a prototype I did for mget that bypasses the claiming phase https://github.com/elastic/kibana/pull/182394/commits/1c2308c6fcefc471773351e5636eea65a13e8d59. The
task_runner.ts
would still need to look at the status of the task before determining if it can return early or if it needs to set the task to running. The mget claim strategy should re-use some code instead of re-defininggetRetryDelay
.Definition of Done
running
statusclaiming
tasks in case the previous code running while Kibana shut down was update by queryclaiming
status