Hi Michael,
Please, can you provide a sample pipeline that reproduces this issue? I suspect this is a result of limitations in how the pipeline is currently scanned for errors (which should be addressed by https://issues.jenkins-ci.org/browse/JENKINS-34038 since the implementation is being completely replaced with a more robust algorithm). However, I would like to confirm this and have a test case I can use to verify.

Hi Sam,

This issue is related to JENKINS-33840 which has an example use case that produces the failed stage, even though the error is caught.

Here is that test case:

node() {
    stage "fail"
    try {
        sh "false"
    }
    catch(err) {
        stage "cleanup"
        sh "true"
    }
    stage "done"
    echo "done"
}

mscharp I've got the root cause, unfortunately it's deeper than it would seem (not visualization). The issue is that an ErrorAction is attached to the executed shell step even though the failure is caught.

For stages, we scan to see if the stage has any nodes with errors on them, and if so we mark the stage as failed: https://github.com/jenkinsci/pipeline-stage-view-plugin/blob/master/rest-api/src/main/java/com/cloudbees/workflow/rest/external/StageNodeExt.java#L133-L135

Now, we could look at steps following this to see if it's safe to ignore the error. But I think that probably the better fix here lies in the actual pipeline execution (and ensuring we have some way to see in the flowgraph if a failure within a step has been caught in another block).

This is clearly a bug, in that we are able to tell from the flow graph whether or not an error was caught within a stage.

But there is also an RFE to allow the script to indicate that a stage should be considered “failed” in some sense despite having caught and handled the exception, and proceeded to the end of the build or subsequent stages. See JENKINS-26522.

jglick Yes, clearly it is a bug that the step shows as errored at the FlowNode level when the error was caught; this represents an undeniable mismatch between the script handling and the DAG representation of the execution. We may assume that the error was ignored somehow if the next node executed successfully, but that is hacky and I think the assumption is likely to bite us in the future.

JENKINS-26522 is one way to handle this - I do like the notion of custom step annotations by attaching an Action to the flownode, but disagree that making it a distinct step is the right course (for cases like this, the best handling is for the execution to attach appropriate information automatically).

My ideal would be either a new StatusAction that takes an arbitrary string (with some standard ones defined), or better yet, a StatusCode field on the FlowNode that does the same (with deserialization logic handling the format before this). Normally I'd suggest an enum, but this use allows definition of custom states specific to plugins. Alternately, status could be an enum with a 'SPECIAL' status option and the ability to attach an action with more status details to support custom states for plugin use.

Error handling behavior would want to mimic freestyle builds