Open matt-brale-xyz opened 1 day ago
Please rebase, as long as we default to opt-in, we can merge it
Thanks! Rebased the PR - should be good to go. Behavior is opt-in - if the new option isn't supplied, it defaults to false and uses the existing retry logic instead of the header to calculate the delay.
It would be useful to be able to configure the Retry middleware to respect the the Retry-After header when it is returned by the server to minimize resources spent on throttled requests on the client and avoid cascading availability issues due to server load from retries.
Proposed setting logic:
:use_retry_after_header - whether to use the Retry-After header to determine the minimum delay before the next retry. If the delay from the header exceeds max_delay, no further retries are attempted. Invalid Retry-After headers are ignored. (boolean, defaults to false)
Proposed implementation https://github.com/elixir-tesla/tesla/pull/639
Please let me know if this is a feature that would fit the standard Retry middleware - I'll rebase the PR if it is.