Merge lp:~jameinel/launchpad/loggerhead-732481 into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Robert Collins | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 12583 | ||||
Proposed branch: | lp:~jameinel/launchpad/loggerhead-732481 | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
183 lines (+56/-16) 2 files modified
lib/launchpad_loggerhead/app.py (+13/-9) lib/launchpad_loggerhead/tests.py (+43/-7) |
||||
To merge this branch: | bzr merge lp:~jameinel/launchpad/loggerhead-732481 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Collins (community) | Approve | ||
Review via email: mp+52902@code.launchpad.net |
Commit message
[r=lifeless][bug=732481] [bug=732496] oops_middleware should call start_response for success, even if there is no body.
Description of the change
This fixes bug #732481. We had a logic snafu. The oops_middleware proxied the 'start_response' call until actual content was written. So that if a bug triggered between the time 'start_response' was called, and when actual content was written, it would have a chance to write its own oops response.
However, it would then only call start_response once it actually started writing content. But now that HEAD requests weren't writing any content, it wasn't actually calling start_response. The WSGI layer would then see that the app returned successfully and would start trying to write the empty-string, but would die because start_response was never called.
Long term, we really could use some black-box tests that actually 'start_loggerhead' and then make a couple requests to it. Probably 1 request on every major page, which would have helped prevent a silly regression like this. But I don't have a good feeling for how to set up a test like that.
I did make sure to do manual "HEAD" requests against a page. Which showed both that it used to fail, and that it is now fixed. As did the 'test_no_