Improve retry middleware option parsing #407
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
britto
force-pushed
the
improve-retry-middleware-option-parsing
branch
2 times, most recently
from
45f7042
to
f5785dd
Compare
|
Hi, thanks for the PR. Raising a proper Silently "fixing" the arguments is a bad practice that can lead to hours of frustrating debugging of an unexpected behaviour. |
|
Hi, @teamon. Thanks for your input on this. I'll update this PR with the changes to make the middleware raise an error instead, hopefully with a helpful message, then I'll ask you to take another look as soon as it's done. |
|
Updated and also seized the opportunity to validate |
teamon
reviewed
Aug 24, 2020
britto
force-pushed
the
improve-retry-middleware-option-parsing
branch
from
5dbaaa1
to
537df80
Compare
By favoring Bitwise.bsl over :math.pow for powers of 2 we make it faster and avoid the need to truncate it afterwards.
…sconfigured
When `delay` or `max_delay` are less than 1, the Retry middleware currently crashes with
the following error:
** (FunctionClauseError) no function clause matching in :rand.uniform_s/2
(stdlib 3.13) rand.erl:326: :rand.uniform_s/2
(stdlib 3.13) rand.erl:299: :rand.uniform/1
(tesla 1.3.3) lib/tesla/middleware/retry.ex:106: Tesla.Middleware.Retry.backoff/3
(tesla 1.3.3) lib/tesla/middleware/retry.ex:94: Tesla.Middleware.Retry.retry/3
It happens because `:rand.uniform/1` requires a positive integer:
https://erlang.org/doc/man/rand.html#uniform-1
This change adjusts `max_delay` to `1` when it isn't positive and also adjusts
`delay` to make sure it is positive and smaller than `max_delay`.
Now we explicitly fail when either one of the following misconfigurations are detected: * `delay` is not a positive integer. * `max_delay` is not a positive integer. * `max_retries` is not a non-negative integer.
britto
force-pushed
the
improve-retry-middleware-option-parsing
branch
from
537df80
to
30b8adf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When
delayormax_delayare less than1, the Retry middleware currently crashes with the following error:It happens because
:rand.uniform/1requires a positive integer.Original idea
Make sure retry won't crash when eitherdelayormax_delayare misconfigured.This change adjustsmax_delayto1when it isn't positive and also adjustsdelayto make sure it falls within1..max_delay. Ideally, I believe we should will raise anArgumentErrorright away when these values are invalid, e.g. when they are not integers, but that would be a bigger, breaking change. So this is a compromise we can safely make for now, without any behavior changes.Update
This change applies strict validation to some retry middleware options. Now we explicitly fail when either one of the following misconfigurations are detected:
delayis not a positive integer.max_delayis not a positive integer.max_retriesis not a non-negative integer.