I think this is a race. In an occurrence of this bug today, the underlying OOPS from the codehosting XML-RPC endpoint was OOPS-a5e70841afac902baac92e35da69db92 at 11:58:39.193Z, and the branch scan job for that push ran from 11:58:37.242Z to 11:58:39.282Z.
The problem may be that, after failing with (probably) an `IntegrityError`, the job infrastructure then tries to insert a `Job` row, but this fails because the transaction has already failed, resulting in an `InFailedSqlTransaction` exception, which doesn't get automatically retried (unlike `IntegrityError`). This is all quite difficult since it's buried inside transaction commit hooks.
I haven't quite figured out what the right thread to pull on here is, but this might give a bit more of a clue.
I think this is a race. In an occurrence of this bug today, the underlying OOPS from the codehosting XML-RPC endpoint was OOPS-a5e70841afac902baac92e35da69db92 at 11:58:39.193Z, and the branch scan job for that push ran from 11:58:37.242Z to 11:58:39.282Z.
The problem may be that, after failing with (probably) an `IntegrityError`, the job infrastructure then tries to insert a `Job` row, but this fails because the transaction has already failed, resulting in an `InFailedSqlTra nsaction` exception, which doesn't get automatically retried (unlike `IntegrityError`). This is all quite difficult since it's buried inside transaction commit hooks.
I haven't quite figured out what the right thread to pull on here is, but this might give a bit more of a clue.