Should SetStatus and ClearStatus Actions Be Used Whenever Abort is?

[lmahoney1]

Hello,

If my workflow uses the Abort action when it encounters an error, should the workflow always be using a combination of ClearStatus and SetStatus?

I have a workflow that errored out due to a parameter value being invalid. I have fixed the parameter value but the log source is still showing that it's in an error state.

I'm seeing a lot of the workflows in this repository use Abort without using ClearStatus or SetStatus. I have found that the Randori workflow does use all three, but it seems less common of the workflows I've looked at.

[ChrisCollinsIBM]

ClearStatus and SetStatus specifically drive the UI status on the Log Source and have INFO/WARN/ERROR possibilities.

ClearStatus clears them ALL and then you can SetStatus as many as you like.

I don't think that Abort provides as much granularity on it's own to achieve that, so if you want updates in the UI and not just the logs I think having all of them makes sense.

There's a good chance the reason supplied to the Abort action will also make it up to the UI but maybe not (or not in the clearest format), we'd have to double check that one.