We have noticed that sometimes, an ABORT on a parent job doesn't actually abort the child job.  Re-aborting the child job is usually successful.

An example log in question might look like this. First, the parent job claims that it aborted the job:

*00:49:04* Aborting all subjobs.
...
00:49:24 Finished Build : #13557 of Job : caffe2-builds/conda2-macos10.13-trigger-build with status : ABORTED

You go look at the log of the job in question, and what do you know: it's still going:

Jenkins >> caffe2-builds >> conda2-macos10.13-trigger-build >> #13557
00:49:2300:49:23  Started by upstream project "Started by ups pytorch-pull-request" build number 18544
00:49:23 originally caused by:
...
00:50:45     >> Job status: [conda2-macos10.13-build] the 'build only if scm changes' feature is disabled.
00:50:45 Starting build job caffe2-builds/conda2-macos10.13-build.

Whenever I see this occur, it does seem like the job is wedged on "Starting build job" in the console; actually, when you look at the build summary page, you will see that the build in question is successfully running.

Anyone seen this before, know what it could be up? We're running Jenkins 2.107.3 and Multijob 1.30. The cancellations are generated automatically by ghprb 1.40.0. We checked the new commits in Multijob 1.31 and they did not seem applicable to our problem. I haven't checked the changelog for newer versions of Jenkins, and am half hoping someone will pipe up saying that this was fixed in such-and-such version of Jenkins.