The semantical difference between "on-complete" and "on-success" + "on-error" is not documented
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mistral |
Fix Released
|
Medium
|
Renat Akhmerov |
Bug Description
The following workflow fails even though 'task2' is success:
wf:
tasks:
task1:
action: std.fail
on-complete:
- task2
task2:
action: std.noop
but if I use on-error and on-success clause to move control to 'task2' workflow goes to success state:
wf:
tasks:
task1:
action: std.fail
on-success:
- task2
on-error:
- task2
task2:
action: std.noop
Even though these two examples look identical they are handled slightly differently in the code. If we explicitly have “on-error” it is treated as “catch” in normal programming languages and it prevents an error from bubbling up. “on-complete” is more like “finally” which doesn’t prevent an exception from bubbling up but rather allows to do some clean up actions.
So, this is expected behavior although it may be confusing.
This needs to be clearly documented.
Changed in mistral: | |
milestone: | none → ocata-2 |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in mistral: | |
assignee: | nobody → jzx (xuange) |
Changed in mistral: | |
assignee: | jzx (xuange) → nobody |
Changed in mistral: | |
milestone: | ocata-2 → ocata-3 |
assignee: | nobody → Renat Akhmerov (rakhmerov) |
Changed in mistral: | |
milestone: | ocata-3 → ocata-rc2 |
Fix proposed to branch: master /review. openstack. org/433557
Review: https:/