Add more info to DisconnectionErrors
Bug #436640 reported by
Diogo Matsubara
on 2009-09-25
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Launchpad itself |
High
|
Diogo Matsubara | ||
Bug Description
As seen in OOPS-1364J216 and OOPS-1364I146 DisconnectionErrors are still happening but we're not sure if this is a soft oops based on the work done on bug 373837 or if this is a real issue.
Related branches
lp:~matsubara/launchpad/bug-436640
- Gary Poster (community): Approve on 2009-10-07
-
Diff: 372 lines6 files modifiedlib/canonical/launchpad/webapp/errorlog.py (+17/-4)
lib/canonical/launchpad/webapp/publication.py (+1/-1)
lib/canonical/launchpad/webapp/tests/test_errorlog.py (+80/-32)
lib/canonical/launchpad/webapp/tests/test_publication.py (+3/-0)
lib/canonical/launchpad/webapp/tests/test_user_requested_oops.py (+10/-0)
lib/lp/bugs/doc/checkwatches.txt (+2/-0)
Gary Poster (gary)
on 2009-10-06
| Changed in launchpad-foundations: | |
| importance: | Undecided → High |
| assignee: | nobody → Diogo Matsubara (matsubara) |
| status: | New → Triaged |
| Gary Poster (gary) wrote : | #1 |
Diogo Matsubara (matsubara)
on 2009-10-07
| Changed in launchpad-foundations: | |
| status: | Triaged → In Progress |
| Changed in oops-tools: | |
| status: | New → In Progress |
| importance: | Undecided → High |
| assignee: | nobody → Diogo Matsubara (matsubara) |
| Changed in launchpad-foundations: | |
| milestone: | none → 3.1.10 |
Fixed in devel r9660 <http://
| Changed in launchpad-foundations: | |
| status: | In Progress → Fix Committed |
| Diogo Matsubara (matsubara) wrote : | #3 |
Fixed in oops-tools trunk r124 <https:/
| Changed in oops-tools: | |
| status: | In Progress → Fix Committed |
Diogo Matsubara (matsubara)
on 2009-10-14
| Changed in oops-tools: | |
| milestone: | none → 3.1.10 |
| Diogo Matsubara (matsubara) wrote : | #4 |
Launchpad part was cherrypicked and lp-oops.
| Changed in oops-tools: | |
| status: | Fix Committed → Fix Released |
| Changed in launchpad-foundations: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Our error reporting utility will have a new method on it called something like "handling" (to parallel the current "raising"). It would be responsible for simply marking the error record as informational. With only this flag, we should be able to see what is
going on for this case, because the zope publisher will raise the exception normally (using "raising") if the retry fails for whatever reason.
We would also presumably use this "handling" method for the ++oops++ handler, wherever that is.
To mark the records as informational, the change needs to be something that your OOPS tool can read. Ideally it would be something that an older version of the OOPS tool will ignore (not fall over) and a newer version would know to identify the OOPS as informational in the DB for filtering, as I said.
If this method works out well for us, we can propose it for the zope package that defines the error reporting utility generally.
Thanks
Gary