requesting code reviews puts the mp into a state where it can't be displayed

[Martin Pool]

i was playing with bug 456643 and bug 487327 by requesting reviews on <https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10854>. (I meant to do this on staging but made a mistake and did it on edge instead.)

This ended up with this mp getting into a state where any attempt to view it gave oops-1427ec27.

I think what I was doing was just requesting reviews from myself and teams to which I belong, with different review types. I think this means (from looking at the traceback) lp got into a state where it allows multiple reviews to be requested in a category where it assumes there will be only one. It may be that you can create two review requests for one person with different types, but the rest of the system can't cope with that.

[Tim Penhey (thumper)]

End state that meant it couldn't be shown:

      name | review_type | name | vote_message | date_created
----------------+-------------+----------------+--------------+----------------------------
 mbp | | jameinel | | 2009-10-06 17:50:49.727095
 bzr | doc | mbp | | 2009-11-27 00:29:45.002283
 mbp | doc | mbp | | 2009-11-27 00:29:29.739284
 ian-clatworthy | <NULL> | ian-clatworthy | 34365 | 2009-10-14 05:29:50.174796

[Martin Pool (mbp)]

At least one way to reproduce this:

on an mp, request a doc review from ~bzr and a code review from ~bzr. Open two windows looking at that mp. In one of them click 'claim' the doc review, in the other click 'claim' the code review. The second submission will error but the mp has already gone into a screwed up state.

[Данило Шеган (danilo)]

Note that executing this on production DB has failed, according to https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus

[Tim Penhey (thumper)]

On Thu, 10 Dec 2009 05:27:09 Данило Шеган wrote:
> Note that executing this on production DB has failed, according to
> https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductio
> nStatus
>

Yes, the db patch didn't land in time for the last rollout.

[Tom Haddon (mthaddon)]

The SQL from https://pastebin.canonical.com/25244/ has been run manually.