I have had a case where I had multiple jobs in the main/master branch of a multibranch pipeline for the same commit. Some of them had succeeded, some had failed and some had been cancelled. Specifically, the latest two ones had succeeded.

All this was because I had just setted up Jenkins, but potentially it could happen in other situations.

The problem is that later, a job for another branch used a cancelled main branch job as reference. That job didn't have any data, so there was nothing to compare against.

It would be good if git-forensics would look at the multiple alternatives and preferred successful jobs over cancelled/unsuccessful ones.

I guess this can be potentially complicated if its made completely generic; in theory the same commit could have been built 3 years ago once and today three times. But I would argue the latest jobs should have preference. If the latest job in my main branch is broken that's on me, but if I had a temporal problem in job #10 and fixed it in job #11 then I would expect job #11 to be used over job #10.