BullMQPluginOptions

connection

Connection options which will be passed directly to BullMQ when creating a new Queue, Worker and Scheduler instance.

If omitted, it will attempt to connect to Redis at 127.0.0.1:6379.

queueOptions

Additional options used when instantiating the BullMQ Queue instance. See the BullMQ QueueOptions docs

workerOptions

Additional options used when instantiating the BullMQ Worker instance. See the BullMQ WorkerOptions docs

concurrency

How many jobs from a given queue to process concurrently.

Can be set to a function which receives the queue name and returns the concurrency limit. This is useful for limiting concurrency on queues which have resource-intensive jobs.

Important implementation note: When using a function, workers are grouped by the concurrency value, not by queue name. Because all Vendure job types are stored in a single BullMQ queue (QUEUE_NAME), any worker can process any job type. This means:

• Multiple Vendure queues returning the same concurrency value will share a worker
• Jobs from different Vendure queues may be processed by the same worker
• The concurrency limit applies to the total jobs processed by that worker, not strictly per Vendure queue

For strict per-queue concurrency isolation, consider:

• Creating separate BullMQ queues per Vendure queue (requires custom implementation)
• Using BullMQ Pro Groups

Example

BullMQJobQueuePlugin.init({  concurrency: (queueName) => {    if (queueName === 'apply-collection-filters') {      return 1;    }    return 5;  }})

setRetries

When a job is added to the JobQueue using JobQueue.add(), the calling code may specify the number of retries in case of failure. This option allows you to override that number and specify your own number of retries based on the job being added.

Example

setRetries: (queueName, job) => {  if (queueName === 'send-email') {    // Override the default number of retries    // for the 'send-email' job because we have    // a very unreliable email service.    return 10;  }  return job.retries;}

setBackoff

This allows you to specify the backoff settings when a failed job gets retried. In other words, this determines how much time should pass before attempting to process the failed job again. If the function returns undefined, the default value of exponential/1000ms will be used.

Example

setBackoff: (queueName, job) => {  return {    type: 'exponential', // or 'fixed'    delay: 10000 // first retry after 10s, second retry after 20s, 40s,...  };}

setJobOptions

This allows you to specify additional options for a job when it is added to the queue. The object returned is the BullMQ JobsOptions type, which includes control over settings such as delay, attempts, priority and much more.

This function is called every time a job is added to the queue, so you can return different options based on the job being added.

Example

// Here we want to assign a higher priority to jobs in the 'critical' queuesetJobOptions: (queueName, job) => {  const priority = queueName === 'critical' ? 1 : 5;  return { priority };}

type

delay