v0.3.32: Honor Retry-After on HTTP 429 and add jittered exponential backoff #27

New Issue

2026-07-01T20:22:24-05:00

jcwalker3 commented

2026-07-01 20:22:24 -05:00

Problem

gitea_auth.api_request is the single HTTP entry point for all Gitea API calls. It has no retry handling: a transient HTTP 429 (rate limit) fails immediately with RuntimeError.

Goal

When an upstream API call returns HTTP 429, api_request should:

Parse and honor Retry-After when present.
Support both seconds-based and HTTP-date Retry-After values.
Fall back to jittered exponential backoff when Retry-After is missing or invalid.
Cap retry delay and retry count via config (env override) with safe defaults.
Use jitter to avoid thundering-herd behavior.
Preserve current behavior for non-429 failures and successful responses.

Acceptance criteria

429 responses honor a valid Retry-After (seconds and HTTP-date).
Invalid/missing Retry-After uses capped jittered exponential backoff.
No infinite retry loops (bounded by max retries).
Deterministic tests via injected clock/sleep and mocked randomness.
Non-429 errors and successful responses unchanged.
No unrelated formatting churn; no secrets/deploy/prod config changes.

Branch: fix/v0.3.32-retry-after-backoff

## Problem `gitea_auth.api_request` is the single HTTP entry point for all Gitea API calls. It has no retry handling: a transient HTTP 429 (rate limit) fails immediately with `RuntimeError`. ## Goal When an upstream API call returns HTTP 429, `api_request` should: 1. Parse and honor `Retry-After` when present. 2. Support both seconds-based and HTTP-date `Retry-After` values. 3. Fall back to jittered exponential backoff when `Retry-After` is missing or invalid. 4. Cap retry delay and retry count via config (env override) with safe defaults. 5. Use jitter to avoid thundering-herd behavior. 6. Preserve current behavior for non-429 failures and successful responses. ## Acceptance criteria - 429 responses honor a valid `Retry-After` (seconds and HTTP-date). - Invalid/missing `Retry-After` uses capped jittered exponential backoff. - No infinite retry loops (bounded by max retries). - Deterministic tests via injected clock/sleep and mocked randomness. - Non-429 errors and successful responses unchanged. - No unrelated formatting churn; no secrets/deploy/prod config changes. Branch: `fix/v0.3.32-retry-after-backoff`

jcwalker3 added the status:in-progress label 2026-07-01 20:22:38 -05:00

jcwalker3 referenced this issue from a commit

2026-07-01 20:29:00 -05:00

feat: honor Retry-After on HTTP 429 with jittered exponential backoff (#27)

jcwalker3 referenced a pull request that will close this issue

2026-07-01 20:29:21 -05:00

v0.3.32: Honor Retry-After on HTTP 429 with jittered exponential backoff #28

sysadmin closed this issue

2026-07-01 21:04:34 -05:00

sysadmin removed the status:in-progress label 2026-07-02 01:30:46 -05:00

Sign in to join this conversation.