We've recently ran into a subtle issue when using ExponentialBackoff through Backoff trait and not retry function. Namely, we've set "public" initial_interval field but not the "private" current_interval field, which then was left with the default 500ms value, which made us scratch our heads about why the first backoff interval is always that long. A call to reset solves that, but it is not obvious from the documentation that it's required in this case.
While as far as I understand the primary use case is through the retry function, it would still be nice to make it "harder" to use the crate incorrectly. The proposal is to introduce a builder which would only set the fields that are intended to be public and not part of the state, and suggest the users to create instances of ExponentialBackoff through the builder in documentation.
If the proposal makes sense, I can also later update the documentation.
We've recently ran into a subtle issue when using
ExponentialBackoff
throughBackoff
trait and notretry
function. Namely, we've set "public"initial_interval
field but not the "private"current_interval
field, which then was left with the default 500ms value, which made us scratch our heads about why the first backoff interval is always that long. A call toreset
solves that, but it is not obvious from the documentation that it's required in this case.While as far as I understand the primary use case is through the
retry
function, it would still be nice to make it "harder" to use the crate incorrectly. The proposal is to introduce a builder which would only set the fields that are intended to be public and not part of the state, and suggest the users to create instances ofExponentialBackoff
through the builder in documentation.If the proposal makes sense, I can also later update the documentation.