Merge lp:~spiv/launchpad/codebrowse-oops-84838 into lp:launchpad
Status: | Superseded | ||||
---|---|---|---|---|---|
Proposed branch: | lp:~spiv/launchpad/codebrowse-oops-84838 | ||||
Merge into: | lp:launchpad | ||||
Prerequisite: | lp:~spiv/launchpad/loggerhead-logging | ||||
Diff against target: |
210 lines (+148/-1) 4 files modified
configs/development/launchpad-lazr.conf (+3/-0) lib/canonical/config/schema-lazr.conf (+9/-0) lib/launchpad_loggerhead/app.py (+134/-0) scripts/start-loggerhead.py (+2/-1) |
||||
To merge this branch: | bzr merge lp:~spiv/launchpad/codebrowse-oops-84838 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Andrew Bennetts (community) | Needs Resubmitting | ||
Michael Hudson-Doyle | Needs Fixing | ||
Review via email: mp+31007@code.launchpad.net |
This proposal has been superseded by a proposal from 2010-07-27.
Description of the change
This fixes a 5-digit bug number. :)
This fixes codebrowse to log tracebacks from failed requests as OOPSes, rather than dumping them in debug.log. This is a fairly basic implementation: it shows very elementary HTML to the user, and it doesn't capture any information in the OOPS beyond the traceback and the URL... but even those flaws are improvements over the status quo, and are clearly marked with XXXs.
The only outstanding issue I know of is finding out what the production config values for this should be, particularly the error_dir. And of course arranging for the production OOPSes to get synced and reported on like OOPS reports from other systems.
This is based on an already-approved (but as yet unmerged) branch that makes a more modest tweak to codebrowse's logging.
1) Yay! misremembering, the wsgi protocol is that the application can return an _iterable_, not necessarily an _iterator_, so I think you need to say "app_iter = iter(app(...))".
2) I think it would be better to have some of the state around 'really-called' etc in an object
3) Unless I'm misreading/
4) The oops page should still be a "500 Internal Server Error" at the HTTP level.
5) Maybe the oops template rendering can be factored out?
6) Yay!, again