Bull queue integration in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a job is added to a Bull queue in NestJS?

Consider a NestJS service that adds a job to a Bull queue using this.queue.add('email', { userId: 123 }). What is the immediate behavior after this call?

NestJS

import { Injectable } from '@nestjs/common';
import { InjectQueue } from '@nestjs/bull';
import { Queue } from 'bull';

@Injectable()
export class EmailService {
  constructor(@InjectQueue('email') private readonly queue: Queue) {}

  async sendWelcomeEmail(userId: number) {
    await this.queue.add('sendEmail', { userId });
  }
}

A The job is stored but requires manual triggering to start processing.

B The job is immediately processed synchronously within the same method call.

C The job is discarded if no worker is listening on the queue.

D The job is added to the queue and processed asynchronously by a separate worker.

💡 Hint

Think about how queues work to handle tasks in the background.

In Bull with NestJS, adding a job to the queue schedules it for asynchronous processing by a worker. The method call returns after adding the job, not after processing it.

📝 Syntax

intermediate

Which code snippet correctly defines a Bull queue processor in NestJS?

You want to create a processor that handles jobs from the 'email' queue. Which option shows the correct way to define this processor?

A

@Processor('email')
export class EmailProcessor {
  @Job('sendEmail')
  async handleSendEmail(job: Job) {
    // process job
  }
}

B

@Processor('email')
export class EmailProcessor {
  @Process('sendEmail')
  async handleSendEmail(job: Job) {
    // process job
  }
}

C

@Queue('email')
export class EmailProcessor {
  @Process('sendEmail')
  async handleSendEmail(job: Job) {
    // process job
  }
}

D

@Processor('email')
export class EmailProcessor {
  @ProcessQueue('sendEmail')
  async handleSendEmail(job: Job) {
    // process job
  }
}

💡 Hint

Look for the decorator that marks a class as a queue processor and the method decorator for job types.

The @Processor decorator marks the class as a Bull queue processor. The @Process decorator marks methods that handle specific job types.

❓ state_output

advanced

What is the state of a Bull job after successful completion?

After a job is processed successfully by a Bull queue worker in NestJS, what is the job's state when you check it using job.getState()?

A "completed"

B "active"

C "failed"

D "waiting"

💡 Hint

Think about the lifecycle states of a job in Bull after finishing without errors.

When a job finishes successfully, its state is "completed". "active" means currently processing, "failed" means error, and "waiting" means queued but not started.

🔧 Debug

advanced

Why does this Bull queue processor never process jobs?

Given this NestJS Bull processor code, why are jobs never processed?

import { Processor, Process } from '@nestjs/bull';
import { Job } from 'bull';

@Processor('email')
export class EmailProcessor {
  @Process('sendEmail')
  async handleSendEmail() {
    console.log('Processing email job');
  }
}

A The @Process decorator is used incorrectly; it should be @Job.

B The queue name 'email' does not match the job name 'sendEmail'.

C The handler method is missing the job parameter, so it never runs correctly.

D The processor class is missing the @InjectQueue decorator.

💡 Hint

Check the method signature for required parameters.

The handler method must accept a Job parameter to receive job data. Without it, the method signature is invalid and the job is not processed.

🧠 Conceptual

expert

How does Bull queue handle job retries in NestJS?

You want a job to retry automatically up to 3 times if it fails. Which configuration option achieves this behavior when adding a job to a Bull queue?

A this.queue.add('sendEmail', data, { attempts: 3 })

B this.queue.add('sendEmail', data, { retry: 3 })

C this.queue.add('sendEmail', data, { maxRetries: 3 })

D this.queue.add('sendEmail', data, { retries: 3 })

💡 Hint

Look for the official Bull option name for retry attempts.

The correct option to specify retry attempts in Bull is 'attempts'. Other options are invalid and will be ignored.