Jesse Glick 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.