Previously, we would respect the Retry-After header to determine the delay time for the retry, but if Retry-After was greater than the retry.maxRetryAfter option, then the retry delay time would be set to 0, effectively canceling it, given Ky's current logic.
We now use maxRetryAfter as a limit for the delay, rather than a threshold for canceling the retry. If Retry-After is greater than maxRetryAfter, then maxRetryAfter will be used as the delay time.
Relates to #390
This PR aims to make retry delays more intuitive.
Previously, we would respect the
Retry-Afterheader to determine the delay time for the retry, but ifRetry-Afterwas greater than theretry.maxRetryAfteroption, then the retry delay time would be set to0, effectively canceling it, given Ky's current logic.We now use
maxRetryAfteras a limit for the delay, rather than a threshold for canceling the retry. IfRetry-Afteris greater thanmaxRetryAfter, thenmaxRetryAfterwill be used as the delay time.