# Scheduler

The scheduler component receives requests from the engine and stores them into persistent and/or non-persistent data structures. It also gets those requests and feeds them back to the engine when it asks for a next request to be downloaded.

## Overriding the default scheduler

You can use your own custom scheduler class by supplying its full Python path in the `SCHEDULER` setting.

## Minimal scheduler interface

class scrapy.core.scheduler.BaseScheduler

  The scheduler component is responsible for storing requests received from the engine, and feeding them back upon request (also to the engine).

  The original sources of said requests are:

  - Spider: `start` method, requests created for URLs in the `start_urls` attribute, request callbacks

  - Spider middleware: `process_spider_output` and `process_spider_exception` methods

  - Downloader middleware: `process_request`, `process_response` and `process_exception` methods

  The order in which the scheduler returns its stored requests (via the `next_request` method) plays a great part in determining the order in which those requests are downloaded. See Request order.

  The methods defined in this class constitute the minimal interface that the Scrapy engine will interact with.

  close(reason: str) → Deferred[None] | None

    Called when the spider is closed by the engine. It receives the reason why the crawl finished as argument and it’s useful to execute cleaning code.

    Parameters:

      reason (`str`) – a string which describes the reason why the spider was closed

  abstractmethod enqueue_request(request: Request) → bool

    Process a request received by the engine.

    Return `True` if the request is stored correctly, `False` otherwise.

    If `False`, the engine will fire a `request_dropped` signal, and will not make further attempts to schedule the request at a later time. For reference, the default Scrapy scheduler returns `False` when the request is rejected by the dupefilter.

  classmethod from_crawler(crawler: Crawler) → Self

    Factory method which receives the current `Crawler` object as argument.

  abstractmethod has_pending_requests() → bool

    `True` if the scheduler has enqueued requests, `False` otherwise

  abstractmethod next_request() → Request | None

    Return the next `Request` to be processed, or `None` to indicate that there are no requests to be considered ready at the moment.

    Returning `None` implies that no request from the scheduler will be sent to the downloader in the current reactor cycle. The engine will continue calling `next_request` until `has_pending_requests` is `False`.

  open(spider: Spider) → Deferred[None] | None

    Called when the spider is opened by the engine. It receives the spider instance as argument and it’s useful to execute initialization code.

    Parameters:

      spider (`Spider`) – the spider object for the current crawl

## Default scheduler

class scrapy.core.scheduler.Scheduler

  Default scheduler.

  Requests are stored into priority queues (`SCHEDULER_PRIORITY_QUEUE`) that sort requests by `priority`.

  By default, a single, memory-based priority queue is used for all requests. When using `JOBDIR`, a disk-based priority queue is also created, and only unserializable requests are stored in the memory-based priority queue. For a given priority value, requests in memory take precedence over requests in disk.

  Each priority queue stores requests in separate internal queues, one per priority value. The memory priority queue uses `SCHEDULER_MEMORY_QUEUE` queues, while the disk priority queue uses `SCHEDULER_DISK_QUEUE` queues. The internal queues determine request order when requests have the same priority. Start requests are stored into separate internal queues by default, and ordered differently.

  Duplicate requests are filtered out with an instance of `DUPEFILTER_CLASS`.

  ### Request order

  With default settings, pending requests are stored in a LIFO queue (except for start requests). As a result, crawling happens in DFO order, which is usually the most convenient crawl order. However, you can enforce BFO or a custom order (except for the first few requests).

  #### Start request order

  Start requests are sent in the order they are yielded from `start()`, and given the same `priority`, other requests take precedence over start requests.

  You can set `SCHEDULER_START_MEMORY_QUEUE` and `SCHEDULER_START_DISK_QUEUE` to `None` to handle start requests the same as other requests when it comes to order and priority.

  #### Crawling in BFO order

  If you do want to crawl in BFO order, you can do it by setting the following settings:

  `DEPTH_PRIORITY` = `1`
  `SCHEDULER_DISK_QUEUE` = `"scrapy.squeues.PickleFifoDiskQueue"`
  `SCHEDULER_MEMORY_QUEUE` = `"scrapy.squeues.FifoMemoryQueue"`

  #### Crawling in a custom order

  You can manually set `priority` on requests to force a specific request order.

  #### Concurrency affects order

  While pending requests are below the configured values of `CONCURRENT_REQUESTS`, `CONCURRENT_REQUESTS_PER_DOMAIN` or `CONCURRENT_REQUESTS_PER_IP`, those requests are sent concurrently.

  As a result, the first few requests of a crawl may not follow the desired order. Lowering those settings to `1` enforces the desired order except for the very first request, but it significantly slows down the crawl as a whole.

  __init__(dupefilter: BaseDupeFilter, jobdir: str | None = None, dqclass: type[BaseQueue] | None = None, mqclass: type[BaseQueue] | None = None, logunser: bool = False, stats: StatsCollector | None = None, pqclass: type[ScrapyPriorityQueue] | None = None, crawler: Crawler | None = None)

    Initialize the scheduler.

    Parameters:

      - dupefilter (`scrapy.dupefilters.BaseDupeFilter` instance or similar: any class that implements the BaseDupeFilter interface) – An object responsible for checking and filtering duplicate requests. The value for the `DUPEFILTER_CLASS` setting is used by default.

      - jobdir (`str` or `None`) – The path of a directory to be used for persisting the crawl’s state. The value for the `JOBDIR` setting is used by default. See Jobs: pausing and resuming crawls.

      - dqclass (class) – A class to be used as persistent request queue. The value for the `SCHEDULER_DISK_QUEUE` setting is used by default.

      - mqclass (class) – A class to be used as non-persistent request queue. The value for the `SCHEDULER_MEMORY_QUEUE` setting is used by default.

      - logunser (bool) – A boolean that indicates whether or not unserializable requests should be logged. The value for the `SCHEDULER_DEBUG` setting is used by default.

      - stats (`scrapy.statscollectors.StatsCollector` instance or similar: any class that implements the StatsCollector interface) – A stats collector object to record stats about the request scheduling process. The value for the `STATS_CLASS` setting is used by default.

      - pqclass (class) – A class to be used as priority queue for requests. The value for the `SCHEDULER_PRIORITY_QUEUE` setting is used by default.

      - crawler (`scrapy.crawler.Crawler`) – The crawler object corresponding to the current crawl.

  __len__() → int

    Return the total amount of enqueued requests

  close(reason: str) → Deferred[None] | None

    1. dump pending requests to disk if there is a disk queue

    2. return the result of the dupefilter’s `close` method

  enqueue_request(request: Request) → bool

    Unless the received request is filtered out by the Dupefilter, attempt to push it into the disk queue, falling back to pushing it into the memory queue.

    Increment the appropriate stats, such as: `scheduler/enqueued`, `scheduler/enqueued/disk`, `scheduler/enqueued/memory`.

    Return `True` if the request was stored successfully, `False` otherwise.

  classmethod from_crawler(crawler: Crawler) → Self

    Factory method which receives the current `Crawler` object as argument.

  has_pending_requests() → bool

    `True` if the scheduler has enqueued requests, `False` otherwise

  next_request() → Request | None

    Return a `Request` object from the memory queue, falling back to the disk queue if the memory queue is empty. Return `None` if there are no more enqueued requests.

    Increment the appropriate stats, such as: `scheduler/dequeued`, `scheduler/dequeued/disk`, `scheduler/dequeued/memory`.

  open(spider: Spider) → Deferred[None] | None

    1. initialize the memory queue

    2. initialize the disk queue if the `jobdir` attribute is a valid directory

    3. return the result of the dupefilter’s `open` method