Merge lp:~roadmr/checkbox/827859 into lp:checkbox
Status: | Merged |
---|---|
Approved by: | Brendan Donegan |
Approved revision: | 1013 |
Merged at revision: | 1038 |
Proposed branch: | lp:~roadmr/checkbox/827859 |
Merge into: | lp:checkbox |
Diff against target: |
40 lines (+12/-0) 2 files modified
checkbox/job.py (+9/-0) debian/changelog (+3/-0) |
To merge this branch: | bzr merge lp:~roadmr/checkbox/827859 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Brendan Donegan (community) | Approve | ||
Daniel Manrique (community) | Needs Resubmitting | ||
Review via email: mp+72786@code.launchpad.net |
Description of the change
This code guards against the situation encountered in bug 827859, where a bogus timeout value can cause the backend to crash. I suspect it may have been caused by the user creating a job with a strange timeout value, but it's good to handle this in the code I think.
I'm turning all strange timeout values to zero, which in practice causes jobs with bad timeouts to outright exit as they don't complete "before" the timeout, but I think this is more desirable than a crashing backend. A possible refinement would be a default (a few seconds) timeout, but I'm not sure it's worth it on safety-net code like this.
Also if you can think of a better way to handle this (this is a bit verbose at 8 lines of code) it would be nice :)
In my opinion it might be better to default to something sensible rather than 0 for the timeout (30 seconds?), I haven't seen an example of a bogus timeout so I'm assuming the would fall under the category of 'programming error'?
Also, I don't think it's really worth changing the code for (as it reads just fine), but this would be shorter (only barely!):
if timeout is not None:
try:
timeout = float(timeout)
if timeout < 0: timeout = 0
except:
timeout = 0 # This could maybe be 30 as a sensible default