This seems to only occur when the blob has lots of attachments -- 36e2e3cc-bedc-11df-98f4-0025b3df357a is problematic, and has 20. I suspect that the problem is BugNotificationRecipient creation: Ubuntu has lots of structural subscribers, and reusing a problematic blob against a product with just a couple works fine. Assuming around 50 subscribers in total for xserver-xorg-video-intel in Ubuntu, 20 attachments would result in 1000 INSERTs on BugNotificationRecipient. Ouch. But this doesn't explain why it's an Apache 502 and not an OOPS-generating timeout.
Another oddity: I saw timeout OOPSes return from staging after 13s, but the 502 returns after slightly over 10s. So the proxy is erroring before a timeout could possibly occur.
This can be reproduced with 'APPORT_STAGING=1 ubuntu-bug linux' and going through the usual filing process on staging. The 502 occurs in the final stage, after the description is entered and the submit button pressed.
This seems to only occur when the blob has lots of attachments -- 36e2e3cc- bedc-11df- 98f4-0025b3df35 7a is problematic, and has 20. I suspect that the problem is BugNotification Recipient creation: Ubuntu has lots of structural subscribers, and reusing a problematic blob against a product with just a couple works fine. Assuming around 50 subscribers in total for xserver- xorg-video- intel in Ubuntu, 20 attachments would result in 1000 INSERTs on BugNotification Recipient. Ouch. But this doesn't explain why it's an Apache 502 and not an OOPS-generating timeout.
Another oddity: I saw timeout OOPSes return from staging after 13s, but the 502 returns after slightly over 10s. So the proxy is erroring before a timeout could possibly occur.
This can be reproduced with 'APPORT_STAGING=1 ubuntu-bug linux' and going through the usual filing process on staging. The 502 occurs in the final stage, after the description is entered and the submit button pressed.