Problem
blasthttp's is_retryable hardcodes HTTP 429 as a retryable status code. When retries >= 1, blasthttp immediately retries 429 responses without honoring Retry-After headers.
BBOT's http module implements its own 429 handling with host-level cooldowns that respect Retry-After. But blasthttp's internal retry fires first, wasting a wire request and ignoring the backoff window.
Currently the only workaround is setting retries=0 on BatchConfig, which also disables retries for connection errors and timeouts.
Proposed Solution
Add a way to opt out of 429 retries per-request while keeping other retries (connection errors, timeouts). For example:
retry_on_429: bool = True on BatchConfig- Or a more general
non_retryable_statuses: list[int] parameter
This would let callers that implement their own rate-limit backoff disable the redundant immediate retry.
Problem
blasthttp's
is_retryablehardcodes HTTP 429 as a retryable status code. Whenretries >= 1, blasthttp immediately retries 429 responses without honoringRetry-Afterheaders.BBOT's
httpmodule implements its own 429 handling with host-level cooldowns that respectRetry-After. But blasthttp's internal retry fires first, wasting a wire request and ignoring the backoff window.Currently the only workaround is setting
retries=0on BatchConfig, which also disables retries for connection errors and timeouts.Proposed Solution
Add a way to opt out of 429 retries per-request while keeping other retries (connection errors, timeouts). For example:
retry_on_429: bool = Trueon BatchConfignon_retryable_statuses: list[int]parameterThis would let callers that implement their own rate-limit backoff disable the redundant immediate retry.