Merge lp:~gary/launchpad/bug744888 into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Aaron Bentley | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 12829 | ||||
Proposed branch: | lp:~gary/launchpad/bug744888 | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
146 lines (+74/-6) 3 files modified
lib/lp/bugs/interfaces/bug.py (+4/-4) lib/lp/bugs/model/bug.py (+3/-0) lib/lp/bugs/tests/test_bug.py (+67/-2) |
||||
To merge this branch: | bzr merge lp:~gary/launchpad/bug744888 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Aaron Bentley (community) | Approve | ||
Review via email: mp+57499@code.launchpad.net |
Commit message
[r=abentley][bug=744888] Snapshots of a bug should not get all of its messages. webservice bug.mute() should work.
Description of the change
This branch hopefully fixes the timeout when muting bug 1 via the webservice. Thanks to investigation by Graham and Robert, the problem appeared to be the fact that, when the webservice made snapshots made snapshots, we got all of the bugs comments ("messages"), and this extra weight pushed us over the timeout. We did that because we snapshotted "messages" and "attachments". Bug 1 has over 1400 comments as of this writing. Robert suggested that simply indicating that these attributes should not be included in snapshots should be sufficient to fix the problem. My branch implements that solution. An ec2 test run seems to indicate that it won't cause any problems.
The most questionable aspect of this is the test. I'll leave the comments to speak for themselves.
Along the way, when I was testing the problem, I discovered that the bug's mute method in the web API was not working as expected. This was getting in the way of my work. I introduced a fix for that in this branch, as well as a test to show that it and unmute both work as the webservice exposes them (unmute already did).
Thank you!
Gary
If StormStatementR ecorder works for your test, I recommend using that instead.
Please change the SQL check as discussed on IRC:
<abentley> gary_poster: I wonder whether there's risk of your SQL check hitting false negatives? Would it be crazy to just look for the string 'message' in the entire statement?
<gary_poster> abentley: looking for message: well...there are also "bugmessage"s in theory...it's obviously a balance between possible false negatives and false positives.
<gary_poster> I guess we could try being a bit more aggressive. I'd be OK with simply splitting on whitespace and making sure there are no strings that start with "message" (which would include tables). If people find that too restrictive in the future they can adjust the test.
Aside from that, looks fine.