ThrottlingRequestManager <T>
Implements
Index
Constructors
Accessors
Methods
Constructors
constructor
Parameters
options: ThrottlingRequestManagerOptions<T>
config: Configuration = ...
Returns ThrottlingRequestManager<T>
Accessors
innerManager
The wrapped manager, holding every request whose domain is not throttled.
Returns T
Methods
[asyncIterator]
Can be used to iterate over the loader instance in a
for await .. ofloop. Provides an alternative for the repeated use offetchNextRequest.Returns AsyncGenerator<CrawleeRequest<Dictionary>, void, unknown>
addRequest
Parameters
requestLike: Source
optionaloptions: RequestQueueOperationOptions
Returns Promise<RequestQueueOperationInfo>
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
requests: RequestsLike
options: AddRequestsBatchedOptions = {}
Returns Promise<AddRequestsBatchedResult>
assertNoStalledDomains
Throws PersistentRateLimitError if any domain has been rate-limiting us past
maxDomainStallSecswithout letting a single request through.A domain qualifies only while it still has queued requests and is actively rate-limiting - a domain that has simply run out of work is finished, not stalled, and one being waited out under a long robots.txt
Crawl-delayis being obeyed, not stonewalled.Returns Promise<void>
drop
Returns Promise<void>
fetchNextRequest
Returns the next request from a domain that is not backing off, or from the inner manager.
Returns
nullwhile 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 ThrottlingRequestManager.isEmpty reportstruemeanwhile so the crawler's task loop idles rather than spins.Returns Promise<null | CrawleeRequest<R>>
getHandledCount
Returns the number of requests in the loader that have been handled.
Returns Promise<number>
getPendingCount
Returns an approximation of the number of pending requests in the loader.
Returns Promise<number>
getTotalCount
Returns an approximation of the total number of requests in the loader (i.e. pending + handled).
Returns Promise<number>
isEmpty
Whether the next ThrottlingRequestManager.fetchNextRequest would return
null.Requests waiting on a throttled domain count as unavailable, so a crawler whose task loop is gated on this idles for the backoff instead of spinning on a fetch that cannot succeed yet.
Returns Promise<boolean>
isFinished
Unlike ThrottlingRequestManager.isEmpty, throttled requests still count as outstanding work.
Returns Promise<boolean>
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.isFinished from ever resolving to
trueand skews the handled and pending counts. See the request lifecycle contract on IRequestLoader.Parameters
request: CrawleeRequest<Dictionary>
Returns Promise<null | void | RequestQueueOperationInfo>
persistState
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
Empties every manager and clears the accumulated backoff. A robots.txt
Crawl-delayis a property of the site rather than of the run, so it survives.Returns Promise<void>
purgeDomainQueues
Empties the per-domain queues, leaving the wrapped manager alone.
Those queues are this manager's own no matter who owns the one it wraps, which is what makes this safe to call where a full
purge()would not be.Returns Promise<void>
reclaimRequest
Reclaims request to the provider if its processing failed. The request will be returned by some subsequent
fetchNextRequest()call.Parameters
request: CrawleeRequest<Dictionary>
optionaloptions: RequestQueueOperationOptions
Returns Promise<null | RequestQueueOperationInfo>
recordDomainDelay
Records a 429 response and puts the URL's domain into backoff.
Parameters
url: string
optionalretryAfterMs: null | number
Returns boolean
falseif the domain is not configured for throttling, in which case this is a no-op.
setCrawlDelay
Records the
Crawl-delaya domain's robots.txt asked for, which becomes its crawl delay unlessminCrawlDelaySecsasks for longer.The first value wins, so a robots.txt re-fetch cannot change the cadence mid-crawl.
Parameters
url: string
delaySeconds: number
Returns boolean
falseif the domain is not throttled, in which case this is a no-op.
setExpectedRequestProcessingTimeSecs
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>
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 returnsnulland ThrottlingRequestManager.isEmpty reportstrue, 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:
Retry-After, and otherwise doubling frombaseDelaySecs. 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 againstmaxRequestRetriesand without penalising its session.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.Example usage: