fixed a small float value of retry_backoff#8295
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #8295 +/- ##
==========================================
- Coverage 87.16% 87.15% -0.01%
==========================================
Files 148 148
Lines 18469 18469
Branches 2524 3148 +624
==========================================
- Hits 16098 16097 -1
- Misses 2092 2094 +2
+ Partials 279 278 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
auvipy
left a comment
There was a problem hiding this comment.
can you please add additional test cases for this change?
|
@auvipy Added tests. |
|
it would be great to add additional integration tests |
|
Added additional tests. @auvipy what kind of integration tests do you expect? I've not found any integration cases in which retry_backoff is used. |
| retry_kwargs['countdown'] = \ | ||
| get_exponential_backoff_interval( | ||
| factor=retry_backoff, | ||
| factor=int(max(1.0, retry_backoff)), |
There was a problem hiding this comment.
are we going to turn everything into 1 only or multiple of 1.0?
There was a problem hiding this comment.
All values less then 1 turn into 1 (except zero). For the other values, the behavior remains the same. I'm using 1.0 (not 1) just for linter.
|
merging with the hope that no regression was introduced! if we got any report, please try to collaborate if needed. thanks for your contribution. |
Note: Before submitting this pull request, please review our contributing
guidelines.
Description
I encountered an unexpected behavior: if I set retry_backoff to 0.0 < {value} < 1.0, all retries will run after default_retry_delay (180 seconds).
I don't think it makes much sense to allow a floating retry_backoff value, so I propose just rounding the {value} up to 1.