Incorrect retry backoff delay calculation

[PetrGlad]

See class ExponentialRety, here.

In case this.unit is not milliseconds, this line will produce unexpected series of delay values. For example, leaving aside workingAttempts suared:

// this.unit == TImeUnit.SECONDS
x = TimeUnit.toSeconds(1) // Let's assume we have got this from builder
x = TimeUnit.toMillis(1) // First iteration
// x == 1000
x = TimeUnit.toMillis(1) // Second iteration
// x == 1000000
// and so on..

So in case unit is not millis then this conversion alone would add at least +/-3 orders of magnitude coefficient. I believe this was not the intention.

I think reasonable approach here would be to move all unit conversions to builder and then default to milliseconds internally.

Possibly related question is regarding this condition workingInterval <= 0. It may become true in case workingInterval <= 0 or workingAttempts == 0. The latter does not hold as it is initially 1 and always increased. workingInterval can be 0 or less only if we have percentOfMaxIntervalForJitter >= 100 which is not checked by builder...
Maybe use one of approaches suggested here instead? They are relatively easier to reason about.

[dehora]

@PetrGlad Thanks for the report - failing test cases would be useful.

[PetrGlad]

OK, it turns out that I cannot trigger this without modifying the ExponentialRetry code. ExponentialRetry.Builder#unit is declared as final with value TimeUnit.SECONDS and this is only value for which workingInterval = unit.toMillis(workingInterval) * (workingAttempts * workingAttempts); would work correctly and this is only time unit for which toMillis is identity.