Skip to content

fix(throttling-manager): Defer throttled 429s without spending retries and give up on persistently rate-limited domains - #2250

Open
Mantisus wants to merge 1 commit into
apify:masterfrom
Mantisus:throttling-429
Open

Mantisus wants to merge 1 commit into
apify:masterfrom
Mantisus:throttling-429

Conversation

@Mantisus

Copy link
Copy Markdown
Collaborator

Description

A 429 from a domain throttled by ThrottlingRequestManager no longer counts as a failure. The request goes back to its queue and waits out the domain's backoff. The retry doesn't count towards max_request_retries or max_session_rotations, the session isn't marked as bad, and the 429 doesn't reach error_handler or failed_request_handler. Setting ignore_http_error_status_codes={429} no longer passes such a response to the request handler.

A domain that keeps rate-limiting every request no longer holds the crawl forever. The new max_domain_stall option on ThrottlingRequestManager (15 minutes by default) sets how long that may last. The crawler still finishes every other domain first, then crawler.run() raises PersistentRateLimitError. The stalled domain's requests stay queued, so a later run can resume them.

New errors (parity with Crawlee TS):

  • RequestThrottledError: the crawler raises it for a throttled 429 and defers the request.
  • PersistentRateLimitError: raised from crawler.run() when a domain has stalled for longer than max_domain_stall.

Issues

Testing

  • Added new unit tests

@Mantisus Mantisus self-assigned this Sep 23, 2026
@Mantisus
Mantisus requested a review from janbuchar September 23, 2026 19:42

This branch has not been deployed

No deployments
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.

ThrottlingRequestManager does not stop a 429 from retiring the session

2 participants