Exponential backoff with jitter of the retry middleware V2 often produces a wait time of 0 ms

[fredericgboutin-yapla]

Describe the bug

I used the retry feature of the AWS Clients thoroughly in the last few years, so much so, that I decided to borrow the very same logic in my own Guzzle client when doing my other API calls (with a custom Guzzle middleware). This is literally the same logic.

I wrote a few unit-tests around my middleware, to ensure that the delay kicks in properly. The tests run in my CI/CD on almost every commit done in our repository (which is a lot over time) and it has been so for many months now.

Last week, the unit tests failed because I was asserting that the delay value should be GREATER than 0. Looking at the logic, yeah 0 is a valid value that I should have included but I didn't. Anyway, I did not have time to adjust the tests, so I just re-ran my unit-tests and it went successfully.

Yesterday, the same unit-test failed again. What are the odds? Not impossible but still... Well, this is were it's getting interesting.

The distribution of mt_rand() return values is biased towards even numbers on 64-bit builds of PHP when max is beyond 2^32. This is because if max is greater than the value returned by mt_getrandmax(), the output of the random number generator must be scaled up.

Source: https://stackoverflow.com/questions/30060396/mt-rand-returns-0

One major difference between Mersenne Twister RNG and a hybrid/hardware approach is that the entire sequence of the random numbers depends on the seed. PHP's mt_srand is used to seed the RNG. Mersenne Twister yields an identical random number sequence for the same seed.

This deterministic nature is useful when an application/game needs to generate values based on a single seed (such as Minecraft). However, Mersenne Twister a bad choice for applications that need to generate random numbers for cryptographic purposes because the internal state of the RNG can be derived by observing the sequences of random numbers the RNG yields.

Source: https://php.watch/articles/testing-php-rand-functions#mt

Bug

Long story short, the exponentialDelayWithJitter() is using the mt_rand function and under certain conditions, it could return 0 or even values more often than not.

Expected Behavior

A more distributed delay value on retry, especially to avoid excessive 0 values.

Current Behavior

I just feel I repeat myself over and over now.

Reproduction Steps

I just feel I repeat myself over and over now.

Possible Solution

I personally fixed it by using the random_int function instead- https://www.php.net/manual/en/function.random-int.php.

For example,

$rand = random_int(1, mt_getrandmax()) / mt_getrandmax();

But I'm not expert here and I'm curious to know what you think we should do.

Additional Information/Context

No response

SDK version used

3.320.9

Environment details (Version of PHP (php -v)? OS name and version, etc.)

7.4 and 8.2 based on the official 64-bit PHP docker images (apache-bullseye)