codebrowse OOPSes with GeneratorExit when connection closed early
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
Critical
|
John A Meinel | ||
Bug Description
Bug #701329's fix eliminated most early socket closure OOPSes from codebrowse, but introduced another:
Traceback (most recent call last):
Module launchpad_
yield data
GeneratorExit
An 'except GeneratorExit: raise' in oops_middleware should fix that. But I don't know how to test it, or even the precise conditions that cause it.
I've verified that this doesn't occur during normal haproxy checks -- a successful HEAD request is not affected. curl --head is unaffected even on a 404, so it seems to require a 404 rendering into a closed connection? jam's reproducer from bug #701329 also works fine as long as the branch exists, but shows this new OOPS locally and on qastaging when the request 404s.
echo -e "HEAD /~jameinel/
OOPS-1891CBA15 is an example on production.
Related branches
- Benji York (community): Approve (code)
-
Diff: 84 lines (+43/-9)2 files modifiedlib/launchpad_loggerhead/app.py (+10/-2)
lib/launchpad_loggerhead/tests.py (+33/-7)
| description: | updated |
| Changed in launchpad: | |
| assignee: | nobody → John A Meinel (jameinel) |
| John A Meinel (jameinel) wrote | #1 |
| John A Meinel (jameinel) wrote Re: [Bug 726985] Re: codebrowse OOPSes with GeneratorExit when connection closed early | #2 |
| Launchpad QA Bot (lpqabot) wrote | #3 |
| Changed in launchpad: | |
| milestone: | none → 11.03 |
| tags: | added: qa-needstesting |
| Changed in launchpad: | |
| status: | Triaged → Fix Committed |
| tags: |
added: qa-untestable removed: qa-needstesting |
| Changed in launchpad: | |
| status: | Fix Committed → Fix Released |
I have a branch which should fix this, but so far, I have been unable to reproduce the failure.
Note that some of the HEAD changes have landed in loggerhead, so it is possible this is hiding the original GeneratorExit failure.