[Bug]: Checked "Always log rows" in "Abort workflow" action leads to wrong flow of execution

[gmitter-ef]

Apache Hop version?

2.15

Java version?

OpenJDK 17

Operating system

Windows

What happened?

An outer workflow calls an inner workflow which calls a pipeline.
The pipeline deliberately fails, which is handled via a "Abort" transform.
The inner workflow recognizes the failing pipeline correctly via the "Failure hop" and calls an "Abort workflow" action.
The outer worklfow then does NOT recognize the failure of the inner workflow and follows the "Success hop" instead of the "Failure hop".

The wrong behaviour occurs if:

• an action SITS BETWEEN the failing pipeline and the "Abort workflow" action in the inner workflow
• in the "Abort workflow" action of the inner workflow, "Always log rows" is CHECKED

If the "Abort workflow" action is DIRECTLY attached to the failing pipeline, the correct behaviour is shown, irrespective of the status of the checkbox.

I believe the "Abort workflow" checkbox should not change the flow of execution, depending on whether actions are in between the failing pipeline and "Abort workflow" or not.

Bug reproduction is inside the attached project (abort-checkbox-bug.zip): see the notes in the workflows.

Expected behaviour (as when checkbox is unchecked):

Observed behaviour (when checkbox is checked):

Issue Priority

Priority: 3

Issue Component

Component: Hop Gui, Component: Actions

[hansva]

Yup, this is not what that option was supposed to do.
It is indeed not setting the workflow as failed, but it is keeping the status from the previous action.

.take-issue

[hansva]

Ah, upon further investigation, it actually does what it is supposed to do, but the documentation is nonexistent.
Going to the original ticket that was raised for this feature: https://issues.apache.org/jira/browse/HOP-3921

When aborting a pipeline, you have multiple options:

• Abort the run, but do not mark it as an error
• Abort the run and mark it as an error

It seems that the request was to have the same options in a workflow. But I am wondering when this would be useful. The only use case I can think of is when a workflow is running in parallel and you want to stop the other running actions but not mark the workflow as failed.

And even if that was the case. Then it should always just abort the workflow and mark it as a success whether the previous action succeeded or failed.

[gmitter-ef]

@hansva

Ah, upon further investigation, it actually does what it is supposed to do

And even if that was the case. Then it should always just abort the workflow and mark it as a success whether the previous action succeeded or failed.

Are these two statements not contradictory? My understanding is that checking or unchecking the checkbox could/should have an influence on marking the workflow as "success" or "failed", but just adding an action (here: "Dummy", but is actually also the case for other actions, e.g. "Set variables") before the "Abort workflow" should not change the result from "failed" to "success".

[hansva]

Currently it seems it is retaining the state from the previous action (which is wrong) so there is an issue

[gmitter-ef]

Thanks for this verification.