Add more info to DisconnectionErrors
Bug #436640 reported by
Diogo Matsubara
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
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
-
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)
| Changed in launchpad-foundations: | |
| importance: | Undecided → High |
| assignee: | nobody → Diogo Matsubara (matsubara) |
| status: | New → Triaged |
Revision history for this message
| Gary Poster (gary) wrote | #1 |
| 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 |
Revision history for this message
| Diogo Matsubara (matsubara) wrote Bug fixed by a commit | #2 |
| Changed in launchpad-foundations: | |
| status: | In Progress → Fix Committed |
Revision history for this message
| Diogo Matsubara (matsubara) wrote | #3 |
| Changed in oops-tools: | |
| status: | In Progress → Fix Committed |
| Changed in oops-tools: | |
| milestone: | none → 3.1.10 |
Revision history for this message
| Diogo Matsubara (matsubara) wrote | #4 |
| 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