Skip to main content
Version: Next

ThrottlingRequestManager <T>

A request manager that wraps another one and paces requests per domain.

Requests for a throttled domain are routed into their own queue when they are added, so each request lives in exactly one place and deduplication keeps working. Everything else goes to the wrapped manager untouched.

fetchNextRequest() serves the domain that has been waiting longest and skips any that are backing off, falling back to the wrapped manager. It never blocks: while every remaining request belongs to a throttled domain it returns null and checkReadiness() reports waiting with the moment the earliest of them comes due, so the crawler idles instead of holding a concurrency slot open.

Each throttled domain runs two independent clocks, and may be dispatched to once both have run out:

  • Backoff, set by HTTP 429 responses - honouring Retry-After, and otherwise doubling from baseDelaySecs. Reactive and temporary: it decays once the domain stops turning us away. The crawlers report the 429s themselves; a request held back this way is retried later without counting against maxRequestRetries and without penalising its session.
  • Crawl delay, the minimum interval between two dispatches to the domain, armed after each one. Proactive and constant: whatever the domain's robots.txt asks for, floored by minCrawlDelaySecs. Either may be absent, in which case the other one is the delay.

Which domains get those clocks is domains - a list, or 'all' for every domain the crawl encounters.

Pass one as a crawler's requestManager; the sameDomainDelaySecs shorthand builds one with domains: 'all' and throttleBy: 'registrableDomain'. Construct it yourself to name the domains or tune the delays - one covering every domain also makes sameDomainDelaySecs land on it as a floor rather than adding a second pacer.

Signals - 429s, robots.txt Crawl-delay, that floor - arrive through recordPacingSignal, which wrapping managers forward, so this works wherever it sits in a composition, including inside a RequestManagerTandem.

Example usage:

const crawler = new CheerioCrawler({
    requestManager: new ThrottlingRequestManager({
        domains: ['api.example.com', 'slow-site.org'],
    }),
    requestHandler: async ({ request }) => { ... },
});

Implements

Index

Constructors

Accessors

Methods

Constructors

constructor

Accessors

innerManager

  • get innerManager(): undefined | T

  • The wrapped manager, holding every request whose domain is not throttled. undefined until an inner passed as a factory is resolved - reading this never forces it, because a getter should not open a queue behind a caller's back.

    Returns undefined | T

Methods

[asyncIterator]

  • Can be used to iterate over the loader instance in a for await .. of loop. Provides an alternative for the repeated use of fetchNextRequest.

    Returns AsyncGenerator<CrawleeRequest<Dictionary>, void, unknown>

addRequest

addRequestsBatched

  • Adds requests in batches, routing each one to the manager that owns its domain.

    Batching, validation, deduplication and Retry-After-free bookkeeping are all delegated to the target managers - this only decides where each request goes, one batch at a time, so a lazy or unbounded input iterable is never fully materialized.

    Parameters

    Returns Promise<AddRequestsBatchedResult>

checkReadiness

  • Reports whether anything can be dispatched right now, and if not, when — or why never.

    One traversal of the domain clocks answers all of it: only domains whose delays have run out are probed, the rest merely contribute the moment they come due. Throttled requests count as outstanding work, so a crawler gated on this idles for the backoff instead of concluding it is done.

    ready from anywhere else outranks a stalling domain and is returned without looking at the stall clocks, so one hopeless domain never ends a crawl making progress elsewhere. It cannot outrank itself, though - see the traversal.

    Returns Promise<RequestSourceStatus>

drop

  • drop(): Promise<void>

  • Returns Promise<void>

fetchNextRequest

  • Returns the next request from a domain that is not backing off, or from the inner manager.

    Returns null while every remaining request belongs to a throttled domain - it never waits the backoff out, because a consumer parked in here holds a concurrency slot, which the autoscaler reads as spare capacity and answers by scaling up. Callers poll instead, and checkReadiness() reports waiting meanwhile so the crawler's task loop idles rather than spins.

    Returns Promise<null | CrawleeRequest<R>>

getHandledCount

  • getHandledCount(): Promise<number>

  • Returns the number of requests in the loader that have been handled.

    Returns Promise<number>

getPendingCount

  • getPendingCount(): Promise<number>

  • Returns an approximation of the number of pending requests in the loader.

    Returns Promise<number>

getTotalCount

  • getTotalCount(): Promise<number>

  • Returns an approximation of the total number of requests in the loader (i.e. pending + handled).

    Returns Promise<number>

markRequestAsHandled

  • Marks a request previously returned by IRequestLoader.fetchNextRequest as handled, removing it from the set of in-progress requests.

    Call this once you are done with the request — whether processing succeeded or was abandoned after exhausting retries. Because a loader cannot take a request back, marking it handled is the only way to signal completion; failing to do so prevents IRequestLoader.checkReadiness from ever reporting finished and skews the handled and pending counts. See the request lifecycle contract on IRequestLoader.

    Parameters

    Returns Promise<null | void | RequestQueueOperationInfo>

persistState

  • persistState(): Promise<void>

  • Persists the current state of the loader into the default KeyValueStore.

    Not all loaders support persistence; implementations that do not should leave this undefined.

    Returns Promise<void>

purge

  • purge(): Promise<void>

  • Empties every manager and clears the accumulated backoff. A robots.txt Crawl-delay is a property of the site rather than of the run, so it survives.

    Returns Promise<void>

reclaimRequest

recordPacingSignal

  • recordPacingSignal(signal): boolean

  • Records something said about the pace requests should go out at, so that a manager which paces its own dispatch can hold requests back.

    Required rather than optional, so that a wrapping manager always forwards it and a pacer nested in a composition still receives it; a manager that does not pace returns false.

    Parameters

    Returns boolean

    true if anything in the composition took responsibility for the signal.

setExpectedRequestProcessingTimeSecs

  • setExpectedRequestProcessingTimeSecs(secs): Promise<void>

  • Tells the manager how long a consumer expects to hold a request fetched via fetchNextRequest() before marking it handled or reclaiming it (typically the request-handler timeout plus padding).

    Managers backed by a storage backend that reserves requests via locking use this to avoid handing the same request out again while it is still being processed. Implementations that do not need this hint may leave it undefined.

    Parameters

    • secs: number

    Returns Promise<void>

Page Options