Spun out of JENKINS-57805 as a separate improvement.

Because Pipeline lazily loads flow nodes as they are needed after a Jenkins restart, almost any caller of methods that end up traversing the flow graph and calling CpsFlowExecution.getNode may end up receiving an IOException due to an invalid FlowNode. Even if that caller is able to handle the error, the flow graph may be left in a corrupted state for other callers (i.e. if FlowNode.loadParents fails, we may have a node in the middle of the flow with no parents). Once the flow graph is corrupted, other callers may run into further issues when they manipulate/traverse the graph, especially because they might not see the original exception and will instead see corrupt/invalid data without necessarily realizing it.

To avoid further issues, it seems safer to try to halt Pipeline execution when CpsFlowExecution.getNode throws an Exception to avoid compounding issues. Whether this can be done safely and in a way that actually improves the situation is not immediately obvious to me, and it would take some experimentation.

A test case that can be adapted to reproduce this kind of problem can be found in https://github.com/jenkinsci/workflow-api-plugin/pull/94.