Skip to content

Cap Retry-After waits to RetryWaitMax in RateLimitLinearJitterBackoff - #296

Closed
Hashim1999164 wants to merge 1 commit into
hashicorp:mainfrom
Hashim1999164:fix/cap-retry-after-rate-limit-backoff
Closed

Cap Retry-After waits to RetryWaitMax in RateLimitLinearJitterBackoff#296
Hashim1999164 wants to merge 1 commit into
hashicorp:mainfrom
Hashim1999164:fix/cap-retry-after-rate-limit-backoff

Conversation

@Hashim1999164

@Hashim1999164 Hashim1999164 commented Aug 12, 2026

Copy link
Copy Markdown

Description

RateLimitLinearJitterBackoff treated Retry-After as an uncapped sleep. A 429 or 503 with a large Retry-After (or a far-future HTTP-date) could stall the client longer than RetryWaitMax.

This caps that wait to max, which is the value callers already pass from Client.RetryWaitMax. DefaultBackoff is left unchanged because #283 already covers that helper.

Related Issue

Fixes #295

How Has This Been Tested?

  • go test ./...
  • go test -count=1 -run TestBackoff_RateLimitLinearJitterBackoff .

Existing cases where Retry-After was larger than max now expect the cap. Added a 3600s Retry-After case with max of 3s.

A 429/503 Retry-After value could previously sleep longer than RetryWaitMax, which stalled clients that treat max as a hard ceiling.
@Hashim1999164
Hashim1999164 requested a review from a team as a code owner August 12, 2026 22:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RateLimitLinearJitterBackoff ignores RetryWaitMax for Retry-After (same as DefaultBackoff)

1 participant