I propose to change the implementation to compute the next retry delay this way:

def nextDelay(attempt /* 1 means called for the first time */, options):
  range = options.first_retry_range
  i = 1
  while i<attempt:
    i++ 
    range = range * options.exponential_base
    if range > options.max_retry_delay :
      break
  delay = options.min_retry_delay + (range - options.min_retry_delay) * random() /* at least min_retry_delay */
  delay = min(options.max_retry_delay, delay) /* at most max_retry_delay */
  return delay

Additionally, the implementation must ensure that the request is not scheduled for retries after
options.max_retry_time elapsed (max_request_time if possible).

options.max_retry_time can be the only meaningful configurable value from the library user POV. Setting to 0 disables retry.

These could be the defaults:

options.first_retry_range = 5 seconds
options.exponential_base = 2
options.max_retry_delay = 125 seconds
options.min_retry_delay = 1 second
options.max_retry_time = 180 seconds

This delay function does no guarantee that delay is increasing. If generated random is a lot smaller than in previous attempt, then resulting delay is also smaller. I have no smart proposal how to fix at this moment though :(

I propose this simple modification to the above algorithm to ensure that delay values are increasing and increasing enough.

+ def randomArbitrary(min, max) {
+  return random() * (max - min) + min;
+ }
...
- delay = options.min_retry_delay + (range - options.min_retry_delay) * random() /* at least min_retry_delay */
+ delay = options.min_retry_delay + (range - options.min_retry_delay) * options.random /* at least min_retry_delay */
...
+ options.random = randomArbitrary(0.5, 1.0)

Or similarly in the PR like

+ self.random = randomArbitrary(0.5, 1.0)
...
- backoff_value = self.backoff_factor * (self.exponential_base ** consecutive_errors_len) * self._random()
+ backoff_value = self.backoff_factor * (self.exponential_base ** consecutive_errors_len) * self.random

Full Jitter is algorithm is described in https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ https://github.com/aws-samples/aws-arch-backoff-simulator/blob/66cb169277051eea207dbef8c7f71767fe6af144/src/backoff_simulator.py#L40

Does it also react the same way when retry is disabled? (max_retry_time is 0)

yes, max_retry_time=0 means retry is disabled, here is the test:

@alespour had a good point that the delays should be increasing (on average), this condition makes it hard to happen since the delay range is the same after a fixed count of attempts, the delays are then oscillating randomly around self.max_retry_delay/2. This can be fixed by restricting the delay range to a large number:

Is this correct?

Please add note how looks formula to compute delay.