bullmq - v6.0.3
    Preparing search index...

    Class JobScheduler

    Base class for all classes that need to interact with queues. This class is normally not used directly, but extended by the other classes.

    Hierarchy (View Summary)

    Index
    constructor
    backend closing keys name opts qualifiedName toKey
    close disconnect emit getBackend getJobSchedulers getScheduler getSchedulersCount isJobScheduler removeJobScheduler trace upsertJobScheduler waitUntilReady
    backend: IQueueBackend

    The datastore backend the queue operates through.

    closing: Promise<void>
    keys: KeysMap
    name: string

    The name of the queue.

    opts: QueueBaseOptions = ...

    Options for the queue.

    qualifiedName: string
    toKey: (type: string) => string

    • Closes the connection and returns a promise that resolves when the connection is closed.

      Returns Promise<void>

    • Emits an event. Normally used by subclasses to emit events.

      Parameters

      • event: string | symbol

        The emitted event.

      • ...args: any[]

        The arguments to pass to the event listeners.

      Returns boolean

      True if the event had listeners, false otherwise.

    • Returns the datastore backend that powers this instance.

      The backend owns its connection(s) and exposes every datastore-agnostic operation through IQueueBackend. Datastore-specific escape hatches (e.g. the raw Redis client) live on the concrete backend implementation, and are exposed here when the class is parameterized on that concrete backend type (the default for the built-in, Redis-backed classes).

      Returns IQueueBackend

    • Checks if a given id corresponds to a registered job scheduler.

      This is used to disambiguate between new job scheduler ids (which may contain any number of colon segments) and legacy repeatable job keys (which always contain 5+ colon segments). Relying purely on segment count is not safe because a user-provided jobSchedulerId may itself contain 5+ colon segments, which would otherwise be misclassified as a legacy repeatable key.

      We cannot use ZSCORE on the shared repeat sorted set because legacy repeatable jobs are stored in the same sorted set and would be reported as schedulers. Instead, we probe the per-id metadata hash (repeat:<id>) for the ic (iteration count) field, which is written exclusively by storeJobScheduler and is never set by the legacy addRepeatableJob flow.

      Parameters

      • id: string

      Returns Promise<boolean>

    • Parameters

      • jobSchedulerId: string

      Returns Promise<number>

    • Wraps the code with telemetry and provides a span for configuration.

      Type Parameters

      • T

      Parameters

      • spanKind: SpanKind

        kind of the span: Producer, Consumer, Internal

      • operation: string

        operation name (such as add, process, etc)

      • destination: string

        destination name (normally the queue name)

      • callback: (span?: Span, dstPropagationMetadata?: string) => T | Promise<T>

        code to wrap with telemetry

      • OptionalsrcPropagationMetadata: string

        The source propagation metadata for telemetry context.

      Returns Promise<T | Promise<T>>

      The result of the callback function.

    • Type Parameters

      • T = any
      • R = any
      • N extends string = string

      Parameters

      Returns Promise<Job<T, R, N>>

    Settings
    Member Visibility

    On This Page
    Constructors
    Properties
    Methods