Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.7.5
-
None
Description
There is a raise condition in request aborting process.
Imagine, we have a request with couple of stages/tasks and one task is in IN_PROGRESS state. Then let's try to abort the request.
Crucial steps of request aborting are:
- Get all not completed tasks for the request.
- Get QUEUED and IN_PROGRESS tasks from #1 and send cancel commands to the agents (we've sent cancel command for our task).
- Get tasks in HOLDING_STATES (HOLDING_FAILED etc.) from #1 and try to abort them.
- Get all tasks form stages which are not in COMPLETED state for the request.
- Get tasks from #4 which are in PENDING, QUEUED, IN_PROGRESS states and abort them.
But if the server receive response from the agent for cancel command (sent in #2), then task will be transitioned from IN_PROGRESS to HOLDING_FAILED state. That's ok if it happen before step #2 (it will be aborted because has HOLDING_FAILED state) or after step #5 (it had IN_PROGRESS state and was aborted; update from the agent won't change state to HOLDING_FAILED, because we handle this case).
But if we receive response from the agent between steps #3 and #5, then task will not be aborted and we will get a task with HOLDING_FAILED state after abort operation completion.
Attachments
Issue Links
- links to