defensive programming on error reporting needed
Bug #637773 reported by
Robert Collins
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
When errorlog code breaks (rare but happens) the appserver breaks the connection abruptly, doesn't log the request properly and users get a generic error page.
The generic page is ok, but we need to still log the request in the access log (so losas can find it) an we need to log the url with th exception (currently goes to nohup.out, which is not ideal).
| Changed in launchpad-foundations: | |
| status: | New → Incomplete |
| status: | Incomplete → Triaged |
| importance: | Undecided → Low |
Revision history for this message
| Gary Poster (gary) wrote | #1 |
To post a comment you must log in.
Per my observations in comment 2 of bug 636697, the captured instance we have of an exception going to nohup.out should not have the characteristics described.
In that instance, I don't believe that the connection was broken, because the exception was caught and ignored while rendering a normal exception page, IOW, this was an exception while rendering the page for an exception, and it was tossed aside, other than be stuffed to stdout/stderr.
bug 647103 is an example of a problem that I believe can cause a broken connection, but it is a very different kind of problem.
Therefore, I vacillate between calling this triaged low and incomplete.
If bug 636697 is *the* source of the nohup.out exceptions, I agree generally with the suggested remediation (I hope there is a better choice than the access log, but maybe not), and we can do it in the zope.exception package. Note that adding the URL may be problematic because the code in question is a library that has no concept of a request.
Otherwise, that is simply one reasonable course of action; other changes may also be needed.