When cancelling a build for a specific Future object, Jenkins currently does not care about actually cancelling the queue item that corresponds to the given future. Instead, it simply cancel the first build for the same task that it can find.

This can be easily replicated by starting two jobs with different parameters via a Groovy script without having any build hosts online (so that they get queued).

The script should hold onto the returned QueueTaskFuture objects and then issue a cancellation on only one of them.

Current Jenkins behaviour is to always cancel the first of the tasks, no matter which of the two future objects were called.

This does not just affect programmatic calling of builds, but can also happen in downstream-triggered tasks and other build starting methods that rely on a cancellation via the QueueTaskFuture instance being reliable.

A new Unittest is going to be provided in the pull request for this scenario.