The cause of this is that by the time the shell step is aborted, CpsFlowExecution reports three running StepExecutions (sh as well as both node steps.)

They all get stop()-ed, and everyone is in a mad rash of cancelling the execution.

In particular, ExecutorStepExecution.stop() declares the whole step a failure, without waiting for the completion of the body blok, which creates a wrong nesting structure.

// Whether or not either of the above worked (and they would not if for example our item were canceled), make sure we die.
getContext().onFailure(new InterruptedException());

The sh step gets independently interrupted, and FutureCallback for the body gets called little bit later, which appends the block body end node.

I think the root cause here is that if the body invocation is in progress, ExecutorStepExecution.stop() should not be invoked. At least for this kind of effectively synchronous step, where the semantics we are going for is that this is just a glorified try-with-resources statement. (parallel might need to behave differently?)

This is the side effect of implementing body invocation as a separate CpsThread. I thought I've put this TODO in a card somewhere, but I can't find it.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to