Error while pushing a bzr branch

[Benjamin Allot]

Hello,

I got this message when trying to push a branch:

$ bzr push lp:~ballot/canonical-mojo-specs/rt123564
Using default stacking branch /+branch-id/16791533 at chroot-140425204915856:///~ballot/canonical-mojo-specs/
<Fault 380: 'An unexpected error has occurred while updating a Launchpad branch. Please report a Launchpad bug and quote: OOPS-1cef28e24bf3b63ac974f3612419dd10.'>
"<Fault 380: 'An unexpected error has occurred while updating a Launchpad branch. Please report a Launchpad bug and quote: OOPS-1cef28e24bf3b63ac974f3612419dd10.'>"
Created new stacked branch referring to /+branch-id/16791533.

The branch seems fine at https://code.launchpad.net/~ballot/canonical-mojo-specs/rt123564.

After a chat with cjwatson, I was also told to report the OOPS ID OOPS-052a44b5a894ddebb086094825b3e2ad here.

Regards,

[Romain Couturat (romaincout)]

I am getting the same kind of issue

$ bzr push lp:~romaincout/canonical-mojo-specs/linuxcontainers-fix-certs2
Using default stacking branch /+branch-id/16791533 at chroot-140126590256688:///~romaincout/canonical-mojo-specs/
<OopsOccurred 380: 'An unexpected error has occurred while updating a Launchpad branch. Please report a Launchpad bug and quote: OOPS-9c721ee209eaaa9d66f49868165ad4e2.'>
"<OopsOccurred 380: 'An unexpected error has occurred while updating a Launchpad branch. Please report a Launchpad bug and quote: OOPS-9c721ee209eaaa9d66f49868165ad4e2.'>"
Created new stacked branch referring to /+branch-id/16791533.
$

That branch couldn't be successfully merged (lp doesn't seem to know about parent)
until pushed a second time, tough this didn't feedback anything of interest:

$ bzr push lp:~romaincout/canonical-mojo-specs/linuxcontainers-fix-certs2
No new revisions or tags to push.
$

[Tom Haddon (mthaddon)]

I just got the same with OOPS-88b7a3b0d7caa80cce329164b7b76144. Re-pushing succeeded the second time.

[Tom Haddon (mthaddon)]

And another occurrence with OOPS-446b830a2f000984f42fc4d87902eb14. Pushing a second time succeeded.

[Tom Haddon (mthaddon)]

And again with OOPS ID OOPS-69a7f07b0c0d728e432eb2a25ed93922.

[Tom Haddon (mthaddon)]

And again with OOPS ID OOPS-277d9297dab05025bdda14e58e637b78.

[Jelmer Vernooij (jelmer)]

I see this about ~50% of the time. Pushing a second time always resolved it.

[Tom Haddon (mthaddon)]

Yep, agreed that pushing a second time always resolves it. Latest OOPS-ID for me is OOPS-bae7cf6ba4e14cc463afb4b3029fd443.

[Colin Watson (cjwatson)]

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.

[Colin Watson (cjwatson)]

This turned out to be https://github.com/zopefoundation/transaction/pull/95.