Skipping Attempts Causing the Retry To Be Unpredictable When Using Longer retryAfter() recovery

[Streebor]

When using retryAfter recovery of 3 seconds, the attempts fail to execute the specified amount of times because the retry logic is skipping attempts.

Here are the logs:

Attempt 1 of 10 failed with error of type `NSError`: `Error Domain=Repository Code=0 "(null)"`. The `recoverFromFailure` closure requested a minimum delay of 2.999796458 seconds before retrying. Will wait 6.580820862 seconds before retrying.
Attempt 5 of 10 failed with error of type `NSError`: `Error Domain=Repository Code=0 "(null)"`. The `recoverFromFailure` closure requested a minimum delay of 2.999975709 seconds before retrying. Will wait 10.97492571 seconds before retrying.
Attempt 6 of 10 failed with error of type `NSError`: `Error Domain=Repository Code=0 "(null)"`. The `recoverFromFailure` closure requested a minimum delay of 2.999974041 seconds before retrying. Will wait 16.07719764 seconds before retrying.
Attempt 8 of 10 failed with error of type `NSError`: `Error Domain=Repository Code=0 "(null)"`. The `recoverFromFailure` closure requested a minimum delay of 2.999976416 seconds before retrying. Will wait 10.288304753999999 seconds before retrying.
Attempt 9 of 10 failed with error of type `NSError`: `Error Domain=Repository Code=0 "(null)"`. The `recoverFromFailure` closure requested a minimum delay of 2.999977584 seconds before retrying. Will wait 8.53429227 seconds before retrying.
Attempt 10 failed with error of type `NSError`: `Error Domain=Repository Code=0 "(null)"`. The `recoverFromFailure` closure requested a minimum delay of 2.999975042 seconds before retrying. No remaining attempts after backing off normally to achieve the minimum delay.

You can see that it is skipping from attempt 1 all the way to attempt 5. Later attempt number 7 is also skipped.

[fumoboy007]

Hi @Streebor!

This is intentional behavior. Here is what the retryAfter documentation says:

It is not guaranteed that the operation will be retried. The backoff process continues until the given instant in time has been reached, incrementing the number of attempts as usual. The operation will be retried only if the number of attempts has not reached maxAttempts.

Let me explain more of the rationale for this behavior. Imagine if the retryAfter value came from a server response (e.g. via the Retry-After HTTP header). If the backoff process did not continue normally, that would mean the server would effectively have full control of the delay. The delay may be arbitrarily long, which may be unexpected for the client.

Instead, with the behavior I implemented, the delay is still bounded according to the client’s retry configuration, so there are no surprises. The client can still opt into longer delays by changing its retry configuration accordingly (e.g. setting maxAttempts to nil).

[fumoboy007]

By the way, what is your use case?

When using retryAfter recovery of 3 seconds, …

Is that what the actual code is doing or was it just for illustration purposes?