Take this PR and comment out optional=true which allows ConsoleLogFilterStep.Execution to be safely restored. Run Jenkins with it, create and attach a JNLP agent, create a Pipeline script running something like

node('agent-name') {
  checkout([$class: 'MercurialSCM', source: 'http://hg.netbeans.org/main-silver/'])
  ant 'build'
}

(or just any long-running Ant project) and start running. Once it is running Ant, restart Jenkins. After the restart, a bit more output will be printed and then the build will hang, irrecoverably. workflow-durable-task-step PR 17 will allow you to see that there is a Guice-related exception. But after that any attempt to abort the build will simply print an error: the sh step already got stopped, so exited with 143 (SIGTERM), but then the consoleLogFilter step's StepContext thinks it too is already finished, and will not allow it to be finished "again". The virtual thread dump says it is in consoleLogFilter. Only a hard kill suffices at this point.

Is there some way to force the CPS VM thread to treat the current StepExecution as a lost cause and really throw its exception up the call stack?