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.

Practice

1. What is the main purpose of integrating Bull queues in a NestJS application?

easy

A. To manage database migrations

B. To create REST API endpoints

C. To handle tasks asynchronously in the background

D. To style the frontend components

Solution

1. Step 1: Understand Bull queue role

   Bull queues are used to process jobs asynchronously, meaning tasks run in the background without blocking the main app.

2. Step 2: Compare options with Bull's purpose

   Database migrations, creating REST API endpoints, and styling frontend components relate to other app parts, not background task handling.

3. Final Answer:

   To handle tasks asynchronously in the background -> Option C

4. Quick Check:

   Bull queues = background task handling [OK]

Hint: Bull queues = background jobs, not API or styling [OK]

Common Mistakes:

• Confusing Bull queues with API routing
• Thinking Bull manages database schema
• Assuming Bull is for frontend styling

2. Which decorator is used in NestJS to define a job handler method for a Bull queue?

easy

A. @QueueJob

B. @QueueHandler

C. @JobListener

D. @Process

Solution

1. Step 1: Recall Bull job handler decorators

   In NestJS Bull integration, @Process decorates methods that handle jobs from a queue.

2. Step 2: Verify other options

   @QueueHandler, @JobListener, and @QueueJob are not valid NestJS Bull decorators.

3. Final Answer:

   @Process -> Option D

4. Quick Check:

   Job handler method uses @Process [OK]

Hint: Job handler methods use @Process decorator [OK]

Common Mistakes:

• Using non-existent decorators like @QueueHandler
• Confusing @Processor with @Process (class vs method)
• Missing the @Process decorator on job methods

3. Given this NestJS Bull processor code snippet, what will be logged when a job with data { name: 'task1' } is processed?

@Processor('email')
export class EmailProcessor {
  @Process('send')
  async handleSend(job: Job) {
    console.log(`Processing job: ${job.data.name}`);
    return 'done';
  }
}

medium

A. Processing job: task1

B. Processing job: undefined

C. Error: job.data is undefined

D. No output because method is not called

Solution

1. Step 1: Understand job data access

   The job object passed to handleSend contains a data property with { name: 'task1' }.

2. Step 2: Analyze console.log output

   The template string uses job.data.name, which is 'task1', so it logs "Processing job: task1".

3. Final Answer:

   Processing job: task1 -> Option A

4. Quick Check:

   job.data.name = 'task1' logs correctly [OK]

Hint: job.data contains the job payload object [OK]

Common Mistakes:

• Assuming job.data is undefined
• Forgetting to await async method
• Thinking method won't be called without explicit call

4. Identify the error in this NestJS Bull queue registration code:

@Module({
  imports: [
    BullModule.registerQueue({
      name: 'notifications',
      redis: {
        host: 'localhost',
        port: '6379'
      }
    })
  ]
})
export class NotificationModule {}

medium

A. The port value should be a number, not a string

B. The queue name must be an array, not a string

C. Redis host cannot be 'localhost', must be IP address

D. BullModule.registerQueue is not a valid method

Solution

1. Step 1: Check Redis config types

   Redis port must be a number, but here it is given as string '6379'.

2. Step 2: Validate other parts

   Queue name as string is valid; 'localhost' is acceptable; BullModule.registerQueue is correct method.

3. Final Answer:

   The port value should be a number, not a string -> Option A

4. Quick Check:

   Redis port must be number [OK]

Hint: Redis port must be numeric, not quoted string [OK]

Common Mistakes:

• Passing port as string instead of number
• Thinking queue name must be array
• Assuming 'localhost' is invalid host
• Confusing BullModule.registerQueue with other methods

5. You want to process two different job types, 'email' and 'sms', in the same NestJS Bull processor class. Which approach correctly handles both jobs?

hard

A. Create two separate @Processor classes, one for 'email' and one for 'sms', each with a single @Process method

B. Use one @Processor('messages') class with two methods decorated by @Process('email') and @Process('sms')

C. Use one @Processor class with a single @Process('email') method handling both job types by checking job.name

D. Register two queues with the same name and use one @Process method

Solution

1. Step 1: Understand @Processor and @Process usage

   A single @Processor class can handle multiple job types from the same queue by defining multiple @Process methods with different job names.

2. Step 2: Evaluate options

   Use one @Processor('messages') class with two methods decorated by @Process('email') and @Process('sms') correctly uses one processor class with two @Process methods for 'email' and 'sms'. Create two separate @Processor classes, one for 'email' and one for 'sms', each with a single @Process method splits into classes unnecessarily. Use one @Processor class with a single @Process('email') method handling both job types by checking job.name cannot handle 'sms' jobs since only 'email' jobs trigger the method. Register two queues with the same name and use one @Process method registers duplicate queues which is invalid.

3. Final Answer:

   Use one @Processor('messages') class with two methods decorated by @Process('email') and @Process('sms') -> Option B

4. Quick Check:

   Multiple @Process methods in one @Processor class [OK]

Hint: One @Processor class can have many @Process methods [OK]

Common Mistakes:

• Creating multiple processor classes unnecessarily
• Using a single named @Process method for multiple job types
• Registering duplicate queues with same name