Events
All classes in BullMQ emit useful events that inform on the lifecycles of the jobs that are running in the queue. Every class is an EventEmitter and emits different events.
Some examples:
import { Queue } from 'bullmq';
const myQueue = new Queue('Paint');
myQueue.on('waiting', (job: Job) => {
// Job is waiting to be processed.
});import { Worker } from 'bullmq';
const myWorker = new Worker('Paint');
myWorker.on('drained', () => {
// Queue is drained, no more jobs left
});
myWorker.on('completed', (job: Job) => {
// job has completed
});
myWorker.on('failed', (job: Job) => {
// job has failed
});The events above are local for the workers that actually completed the jobs. However, in many situations you want to listen to all the events emitted by all the workers in one single place. For this you can use the QueueEvents class:
import { QueueEvents } from 'bullmq';
const queueEvents = new QueueEvents('Paint');
queueEvents.on('completed', ({ jobId }) => {
// Called every time a job is completed in any worker.
});
queueEvents.on(
'progress',
({ jobId, data }: { jobId: string; data: number | object }) => {
// jobId received a progress event
},
);The QueueEvents class is implemented using Redis streams. This has some nice properties, for example, it provides guarantees that the events are delivered and not lost during disconnections such as it would be the case with standard pub-sub.
DANGER
The event stream is auto-trimmed so that its size does not grow too much, by default it is ~10.000 events, but this can be configured with the streams.events.maxLen option.
Real-time updates
Local Worker / Queue listeners only see events in the current process. QueueEvents is the usual building block for real-time updates across workers: dashboards, websockets, SSE, or another service that must react while jobs run.
import { QueueEvents } from 'bullmq';
const queueEvents = new QueueEvents('Paint', { connection });
queueEvents.on('completed', ({ jobId, returnvalue }) => {
sendToDashboard({ type: 'completed', jobId, returnvalue });
});
queueEvents.on('failed', ({ jobId, failedReason }) => {
sendToDashboard({ type: 'failed', jobId, failedReason });
});
queueEvents.on(
'progress',
({ jobId, data }: { jobId: string; data: number | object }) => {
sendToDashboard({ type: 'progress', jobId, data });
},
);Publish progress from the worker with job.updateProgress(...) (number or object). That pairs well with working with batches when one job represents many items, or when you want a live bar for a long job:
await job.updateProgress({ completed: 3, total: 10 });Close QueueEvents on shutdown so its Redis connection is released:
await queueEvents.close();INFO
For jobs processed with BullMQ Pro batches, worker-local completed / failed listeners see the wrapper batch job. Use QueueEvents / QueueEventsPro when you need per-job lifecycle events.
Manual trim events
In case you need to trim your events manually, you can use trimEvents method:
import { Queue } from 'bullmq';
const queue = new Queue('paint');
await queue.trimEvents(10); // leaves 10 eventsfrom bullmq import Queue
queue = Queue('paint')
await queue.trimEvents(10) # leaves 10 eventsuse bullmq::{Queue, QueueOptions};
let queue = Queue::new("paint", QueueOptions::default()).await?;
queue.trim_events(10).await?; // leaves 10 events