Skip to content

feat(renderer): proxy-retry on origin rate-limit (429)#194

Merged
us merged 1 commit into
mainfrom
feat/proxy-on-ratelimit
Jun 27, 2026
Merged

feat(renderer): proxy-retry on origin rate-limit (429)#194
us merged 1 commit into
mainfrom
feat/proxy-on-ratelimit

Conversation

@us

@us us commented Jun 27, 2026

Copy link
Copy Markdown
Owner

A 429 (origin rate-limiting our egress IP) now triggers ONE retry through a configured proxy (CRW_HTTP_RATELIMIT_PROXY_URL) — a different egress IP clears the limit, so the engine stops stalling behind a single shared IP when a large proxy pool is available. Opt-in (unset=unchanged). Mirrors the relaxed-TLS fallback; SSRF unaffected. Fixes the real-world case where high-volume scraping (or multi-engine scale tests) hit per-IP rate-limits.

An HTTP fetch the origin rate-limits with 429 is now retried ONCE through a
configured proxy (`CRW_HTTP_RATELIMIT_PROXY_URL`, e.g. a residential/datacenter
gateway) — a different egress IP usually clears the limit, so the engine no
longer stalls behind a single shared egress IP when a large proxy pool is
available. Opt-in: unset/empty = behavior identical to before. Mirrors the
relaxed-TLS fallback (a per-trigger fallback client + a one-shot flag in the
fetch loop, no retry-budget consumption). The cert/relaxed and transient-retry
paths are untouched; SSRF protection is unaffected (it runs on the resolved
target URL, not the proxy hop).
@us us merged commit da7ecda into main Jun 27, 2026
@us us deleted the feat/proxy-on-ratelimit branch June 27, 2026 08:13
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.

1 participant