GitHub user AviaE opened a pull request:
https://github.com/apache/incubator-ariatosca/pull/110
Improve execution cancelling
Unhandled execution status transitions resulting from cancelling an
execution via the CLI, that we indentified and tried to address:
1. TERMINATED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already finished, and therefore, in
SUCCEEDED status.
2. FAILED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already encountered an error, and
therefore, in
FAILED state.
3. TERMINATED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.
4. FAILED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.
In all of the above cases (#1-#4), we skip updating the execution status,
and log that the execution already succeeded/failed before we were able
to cancel it.
5. CANCELLING -> STARTED
You cancel the execution while it is still in pending state. Meanwhile,
while the execution status was already set to CANCELLING, we try to set
the execution status
6. CANCELLED -> STARTED
Similar to #5, but after the status is set to CANCELLING, it also gets
set to CANCELLED before attempting to set it to STARTED.
In cases #5-#6, we skip updtating the execution status, and nothing is
logged.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/incubator-ariatosca
ARIA-143-improve-cancelling-of-workflow-execution
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-ariatosca/pull/110.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #110
----
commit 4e81d7fff45bae1a2ccb9f0b897179c95076cf3f
Author: Avia Efrat <[email protected]>
Date: 2017-04-20T10:23:32Z
Improve execution cancelling
Unhandled execution status transitions resulting from cancelling an
execution via the CLI, that we indentified and tried to address:
1. TERMINATED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already finished, and therefore, in
SUCCEEDED status.
2. FAILED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already encountered an error, and
therefore, in
FAILED state.
3. TERMINATED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.
4. FAILED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.
In all of the above cases (#1-#4), we skip updating the execution status,
and log that the execution already succeeded/failed before we were able
to cancel it.
5. CANCELLING -> STARTED
You cancel the execution while it is still in pending state. Meanwhile,
while the execution status was already set to CANCELLING, we try to set
the execution status
6. CANCELLED -> STARTED
Similar to #5, but after the status is set to CANCELLING, it also gets
set to CANCELLED before attempting to set it to STARTED.
In cases #5-#6, we skip updtating the execution status, and nothing is
logged.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
