Merge lp:~wgrant/launchpad/no-key-oopses into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | William Grant | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 14071 | ||||
Proposed branch: | lp:~wgrant/launchpad/no-key-oopses | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
240 lines (+55/-50) 5 files modified
lib/lp/archiveuploader/nascentupload.py (+2/-15) lib/lp/archiveuploader/tests/nascentupload.txt (+2/-2) lib/lp/archiveuploader/tests/test_uploadprocessor.py (+31/-23) lib/lp/archiveuploader/uploadprocessor.py (+17/-7) lib/lp/soyuz/doc/soyuz-upload.txt (+3/-3) |
||||
To merge this branch: | bzr merge lp:~wgrant/launchpad/no-key-oopses | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jeroen T. Vermeulen (community) | Approve | ||
Review via email: mp+77447@code.launchpad.net |
Commit message
[r=jtv][bug=862032] Don't OOPS on FatalUploadErrors. Even though we can't tell anyone about them, they are still user error.
Description of the change
This branch fixes some user-error Soyuz OOPSes: FatalUploadErrors from process-upload.
FatalUploadErrors are caused by ChangesFile in case of signature issues (no signature, bad signature, unrecognized key, etc.) or corrupt changes files. Since we use the changes file to determine the notification recipient, such a failure means that we're unable to email anyone about it.
Long ago it was decided to turn such unreportable user errors into OOPSes. But that runs counter to ZeroOopsPolicy, so we should not do it. This branch logs them at DEBUG instead, with the rest of the normal processing stuff.
This is a change that I've been craving. So much kudos for implementing it.
I heartily approve of most of this branch. Of course as a reviewer, I have a reputation to uphold and thus:
=== modified file 'lib/lp/ archiveuploader /nascentupload. py' archiveuploader /nascentupload. py 2011-08-23 14:35:43 +0000 archiveuploader /nascentupload. py 2011-09-29 05:22:06 +0000
--- lib/lp/
+++ lib/lp/
@@ -114,23 +110,14 @@ e_path( cls, changesfile_path, policy, logger):
def from_changesfil
"""Create a NascentUpload from the given changesfile path.
- May raise FatalUploadError due to unrecoverable problems building
+ May raise UploadError due to unrecoverable problems building
the ChangesFile object.
If we're crossing the boundary of "fatal" here, consider replacing or removing the word "unrecoverable" as well. It's not so much the error that is unrecoverable, as an extent of code. But what extent exactly? Like "Fatal," "unrecoverable" sort of suggests that that extent is the entire script run.
=== modified file 'lib/lp/ archiveuploader /tests/ test_uploadproc essor.py' archiveuploader /tests/ test_uploadproc essor.py 2011-08-26 06:14:54 +0000 archiveuploader /tests/ test_uploadproc essor.py 2011-09-29 05:22:06 +0000
--- lib/lp/
+++ lib/lp/
@@ -1361,28 +1363,27 @@
self. options. builds = False rocessor( self.layer. txn)
processor = self.getUploadP
- upload_dir = self.queueUploa d("foocomm_ 1.0-1_proposed" ) le_data = ''' write(bogus_ changesfile_ data) d("foocomm_ 1.0-1_proposed" )
- bogus_changesfi
- Ubuntu is a community developed, Linux-based operating system that is
- perfect for laptops, desktops and servers. It contains all the
- applications you need - a web browser, presentation, document and
- spreadsheet software, instant messaging and much more.
- '''
- file_handle = open(
- '%s/%s' % (upload_dir, 'bogus.changes'), 'w')
- file_handle.
- file_handle.close()
+ self.queueUploa
+
+ # Any code that causes an OOPS is a bug that must be fixed, so
+ # let's monkeypatch something in that we know will OOPS.
I find this explanation unnecessarily confusing. To a hurried reader (and we all are from time to time) it seems to say "let's create bugs that must be fixed," which of course is fine from a job-security standpoint but...
What I think you mean is: "This test verifies that oopses get handled properly, which is very important because oopses must be caught and fixed. The following simulates an error that will be treated as an oops. We verify that the oops gets handled properly later."
If so, the first of those sentences probably belongs at the top of the test (if roughly the same thing isn't being said there already), and the last belongs at the point of verification.
For some reason the term "let's" seems to be a very reliable indicator of this kind of muddled expression in tests, so treat it as inherently suspicious.
+ class SomeException( Exception) : e_path( cls, changesfile_path, policy, logger):
+ pass
+
+ def from_changesfil
+ raise SomeException("I am an explanation.")
+ ...