Consider a NestJS Bull queue where you add a named job twice with the same name but different data. What will be the behavior?
await queue.add('email', { to: 'a@example.com' }); await queue.add('email', { to: 'b@example.com' });
Think about how queues handle jobs with the same name but different data.
Named jobs in Bull are just labels. Adding two jobs with the same name but different data creates two separate jobs. They are processed independently in the order they were added.
Choose the correct syntax to add a named job called 'cleanup' that repeats every hour.
Remember the method signature: add(name, data, options).
The correct syntax uses the job name as the first argument, job data as the second, and options (including repeat) as the third argument.
Given the following code, why does the named job 'processData' never execute?
queue.process('processData', async (job) => { console.log('Processing:', job.data); }); await queue.add('processdata', { id: 1 });
Check the exact spelling and casing of job names.
Job names are case sensitive. The job was added with name 'processdata' but the processor listens for 'processData'. They do not match, so the job is never processed.
Consider this sequence:
await queue.add('task1', {});
await queue.add('task2', {});
const job = await queue.getJob('task1');
await job?.remove();
const count = await queue.count();What is the value of count?
Check the parameter type expected by getJob().
The getJob() method expects a job ID, not a job name. Passing a name returns null, so job?.remove() does nothing. The count remains 2.
In NestJS Bull, if you define multiple processors for the same named job with different concurrency values, what happens?
Think about how Bull distributes jobs to processors.
Bull allows multiple processors for the same named job. Each processor runs independently with its own concurrency. Jobs are distributed among them.