Because Bodhi server sometimes returns Internal Server Error
(HTTP 500), BodhiUtils retries its request N-times.
Details
- Reviewers
kparal tflink mkrizek - Maniphest Tasks
- T338: implement retries for failed read-only bodhi calls
- Commits
- rLTRNb1d4de3123c3: retry Bodhi request if server returns HTTP 5xx
py.test testing/ (added two tests for query retries)
Diff Detail
- Repository
- rLTRN libtaskotron
- Branch
- arcpatch-D239_1
- Lint
No Linters Available - Unit
No Unit Test Coverage
Overall, a good start.
I'm wondering if it would be better to broaden this so that failed requests are retried instead of just retrying on 500s. Any other thoughts?
| libtaskotron/bodhi_utils.py | ||
|---|---|---|
| 59–75 | please use a more descriptive var name than i. Something like num_retries or retries would be better | |
| 70 | why not use e.code != 500 here instead of < and >? | |
About that retrying on all errors - what about when server returns 404?
| libtaskotron/bodhi_utils.py | ||
|---|---|---|
| 70 | That's because Kamil checked it and server sometimes returns 500, sometimes 503. I was not sure whether it can return other errors, so it retries it on all 500 Server errors. | |
I suppose that 5XX errors are the ones that we're most interested in but on the other hand, why would retrying on 404s be a bad thing?
I'm fine with either approach, though. This has the most important cases covered
| libtaskotron/bodhi_utils.py | ||
|---|---|---|
| 70 | oh, I see now. sorry - read too quickly | |
Just one nitpick.
| libtaskotron/bodhi_utils.py | ||
|---|---|---|
| 75 | The message is somewhat confusing though. If the server is always unavailable we get: and that's it, where's (3 from 3)? :) Sure, we try querying the server three times, but the message is confusing. What about changing the message to something like 2 retries remaining? | |
Otherwise LGTM. I will commandeer this revision, wait for kamil's feedback and push it.
| libtaskotron/bodhi_utils.py | ||
|---|---|---|
| 68 | I think that there is off-by-one error. xrange(1,X) generates numbers from 1 to X-1, so retry_num will never be equal to max_retries. I think that running tests confirms it. | |
If you want to make it pretty, you can use