Recommend increasing the priority, as this bug can render your Jenkins installation unusable and unrecoverable.

I ran the following workflow:

def nothing = [:]
node {
parallel nothing
}

and now there is a "build" consuming one executor on a slave. This build cannot be killed and survives Jenkins restarts. Even deleting the slave entirely cannot recover the situation. Nothing short of nuking JENKINS_HOME from orbit seems to get rid of it.

Clearly this workflow is silly, but it would be pretty easy to do the equivalent accidentally if your Groovy script dynamically built up a set of blocks to run (like the "splitTests" demo in the documentation does). And the consequences currently are pretty dire.

FYI the workaround on JENKINS-25550 (appending /doDelete to the build URL) doesn't work either. It removes the build in that the URL for the build returns 404, but the "part of foo" build is still consuming an executor on the slave.

Also FYI, even deleting the Workflow itself doesn't fix it. Executors still in use (although that at least cleared any queued runs).

Ahh... deleting the Workflow job, and then stopping and starting Jenkins finally did the trick. All executors free, and the phantom slave is gone.

(FYI I initially tried to use the <jenkins>/restart URL to restart Jenkins, and the Java process went into a 100% CPU busyloop. But killing it and restarting Jenkins finally put things right.)

This is still a pretty severe consequence of a trivial bug in a workflow script.

You need to delete the build as mentioned in JENKINS-25550, then restart.

Good to know the work-around, but IMHO at least this is still a significant bug as the consequences are severe and the work-around is pretty hidden.