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) |
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.