The use cases are:
- abort a very long command run by mistake
- abort a command that is in error and that blocks other commands on the same action
A command in error is a possible case when:
- The action doesn't respect their contract:
- stop on an error that should be expected (like the user doesn't have enough permission)
- doesn't validate its parameters and invalid input generates an error
- don't report enough processed documents and stay in running state (this is not a blocking case)
- The KV store has been flushed and action and status computation cannot found command or status.
Being able to cancel a command providing its identifier will enable to recover from such situation.
Possible implementation:
- a bulk service abort method will set the status of the command to something like ABORTED
- AbstractBulkComputation when not able to retrieve the command will check its status, in case of abort we skip the record instead of terminating in error
- BulkStatusComputation will simply ignore record with the ABORTED status
- the bulk service await should return true on aborted command
Depending on when the command has been aborted, we can have:
- a completed command because the abort is receive after the completion
- a complete cancelation of the command if the action has not been applied on any document
- a partial command where a part of the document set has been processed
The status is written to the done stream as way to give feedback on downstream processing.
A possible rest endpoint can be:
curl -s -X PUT "http://localhost:8080/nuxeo/api/v1/bulk/$commandId/abort" -u Administrator:Administrator -H 'content-type: application/json' # returns the status so we know if the command has been ABORTED or if it is already COMPLETED
- is related to
-
NXP-25990 NullPointer when processing BulkStatusComputation.
- Resolved