Upload processing may reach a transaction deadlock when closing bugs

[Celso Providelo]

Logging of the incident:

{{{
2009-07-28 11:45:11 DEBUG Created i386 build of torbutton 1.2.1-1ubuntu2 in ubuntu karmic RELEASE [1137540] in Primary Archive for Ubuntu (1755)
2009-07-28 11:45:11 DEBUG Closing bugs.
/srv/launchpad.net/codelines/soyuz-production-rev-8312/lib/lp/bugs/model/bugtask.py:648: UserWarning: shortlist() should not be used here. It's meant to listify sequences with no more than 15 items. There were 26 items.
  return self.getConjoinedMaster(shortlist(self.bug.bugtasks))
2009-07-28 11:45:14 ERROR Exception while accepting: deadlock detected
DETAIL: Process 18239 waits for ShareLock on transaction 184906003; blocked by process 772.
Process 772 waits for ShareLock on transaction 184905870; blocked by process 18239.
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."bug" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
 -> http://launchpadlibrarian.net/29615810/2xhALOBJneX97lQ9BJVkZ1tItvT.txt (deadlock detected
DETAIL: Process 18239 waits for ShareLock on transaction 184906003; blocked by process 772.
Process 772 waits for ShareLock on transaction 184905870; blocked by process 18239.
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."bug" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x")
}}}

[Celso Providelo (cprov)]

The whole transaction was aborted and no email was sent.

We can't really avoid the deadlock (which was probably caused by concurrent changes to the bug) but we certainly could at least send the rejection-message.

In an ideal scenario we may also retry the transaction.

[Robert Collins (lifeless)]

Upload processing has been overhauled since this, and can/should be made into an API (of some sort) client I think, which would eliminate room for such things. conflicts can occur on any row the upload processor is working on; the right thing to do is what the appservers do: retry the whole transaction, not fail the upload.