Hello, we are finding that one of our queues is periodically getting stuck, with 2 jobs sitting in "active" and not being progressed for 18 hours, while the "waiting" queue is filling up with 1000's of jobs as a result.

The jobs failed with an error, but are not being removed from the "active" state. What can be done to address this? The queue should not get stuck as a result requiring manual intervention, as this is making bullmq completely unusable for us.

Please let me know what further information you need to help analyse this. Please don't ask for a "script to reproduce" because we don't have one. It's a complicated app with dozens of different jobs, and the jobs that are failing are not always failing, just occasionally when Chrome fails to load on the instance.

Thanks.

These two functions are different from v3 and I just don't know what to set for the token.

job.moveToFailed(new Error('failed message'), ???);

Thanks for developing this open source. I really enjoy it. I have encountered this problem when running on vercel serverless. The source code works perfectly fine on local.

{
  "errorType": "Runtime.UnhandledPromiseRejection",
  "errorMessage": "TypeError: client.addJob is not a function",
  "reason": {
    "errorType": "TypeError",
    "errorMessage": "client.addJob is not a function",
    "stack": [
      "TypeError: client.addJob is not a function",
      " at Function.addJob (/var/task/node_modules/bullmq/dist/classes/scripts.js:52:23)",
      " at Job.addJob (/var/task/node_modules/bullmq/dist/classes/job.js:352:34)",
      " at Function.create (/var/task/node_modules/bullmq/dist/classes/job.js:34:28)",
      " at processTicksAndRejections (internal/process/task_queues.js:93:5)",
      " at Queue.add (/var/task/node_modules/bullmq/dist/classes/queue.js:38:25)"
    ]
  },
  "promise": {},
  "stack": [
    "Runtime.UnhandledPromiseRejection: TypeError: client.addJob is not a function",
    " at process.<anonymous> (/var/runtime/index.js:35:15)",
    " at process.emit (events.js:327:22)",
    " at process.emit (/var/task/___vc_sourcemap_support.js:587:21)",
    " at processPromiseRejections (internal/process/promises.js:245:33)",
    " at processTicksAndRejections (internal/process/task_queues.js:94:32)"
  ]
}

Example Code:

const connection = new IORedis(process.env.REDIS_URI);
const queue = new Queue('SENDEMAIL', { connection });
const job = await queue.add('SEND',  { email });

I found a workaround for this while customizing the vercel.json file. Hope to be able to help anyone who is having this problem.

    "functions": {
        "api/serverless.ts": {
            "includeFiles": "node_modules/bullmq/dist/commands/**",
        }
    },

We have a relatively straightforward integration of this library on Heroku (that generally follows this guide):

1. worker process – small Node.js process that instantiates a Worker instance, leveraging throng / clustering
2. web process – Express server instantiates a singleton ioredis connection and Queue instance; in practice, some of our Express routes add a job to the queue

We're instantiating the ioredis connection like so:

new IORedis(redisUrl, {
  maxRetriesPerRequest: null,
  enableReadyCheck: false,
});

per the recommendation added in https://github.com/taskforcesh/bullmq/pull/836.

Is this the recommended Express setup? We're specifically concerned that disabling maxRetriesPerRequest will pose issues in our web context where ideally the number of retries would be finite (per ioredis' default) and commands would "fail fast" to deliver a timely HTTP response.

Upgrading BullMQ from 1.55.1 to 1.16.0 results in this error:

import { Queue } from 'bullmq'
         ^^^^^
SyntaxError: Named export 'Queue' not found. The requested module 'bullmq' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'bullmq';
const { Queue } = pkg;

Changing my code to this worked indeed, but it's not ideal:

import bull from 'bullmq'
const { Queue } = bull;

I can't find which commit caused it, but it would be nice to have this fixed.

I had a job that reported as "Stalled". In redis there was a lock, an entry in the stalled key. Nothing seemed to be wrong, but the stalled job did not reprocess and the subsequent jobs did not process either.

the worker is a sandboxed worker, the original work process did not break or have an error from what i can see.

I have a queue class that automatically instantiates queue, the worker shares a connection with the queue. then i have a queue scheduler and queue events all with their own connection.

any ideas?

not sure if this makes a difference but i do make use of job.waitUntilFinished(this.queueEvents)

Bullmq 1.8.7 Redis: elasticache Nodejs 12.18.3

If I have more workers than processes on an instance I'm wondering if this will this cause any issues? What happens in this situation?

I just added about 5 additional queues (starting from 14) and workers and I believe it has caused caused an issue where we are building up waiting events and all the queues seem blocked. I manually retriggered one job from arena gui and it appeared to go active then bounce back to waiting immidiately.

I removed the additional queues & related workers/schedulers and it immediately completed the jobs very quickly so it appears as if we've hit some limit but I'm unsure what is most likely to be blocking.

Could this be a bug in our new workers? We don't have a lot of throughput so I wouldnt have thought it would have completely blocked every queue but there is probably something I'm not understanding.

I am getting the following error after upgrading to 1.40.1

| Error: Connection is closed. | at Redis.endHandler (/var/www/api/rest-server/node_modules/bullmq/dist/classes/redis-connection.js:53:24) | at Object.onceWrapper (events.js:422:26) | at Redis.emit (events.js:315:20) | at processTicksAndRejections (internal/process/task_queues.js:75:11)

this happens when shutting down the server where my code was trying to close bullmq connections with code below

queueScheduler && await queueScheduler.close(); queue.getTaskQueue() && await queue.getTaskQueue().close(); worker && await worker.close();

In bull3, there's a job option (timeout)

In bullmq4, it is commented out in worker.ts:

 if (timeoutMs) {
        jobPromise = jobPromise.timeout(timeoutMs);
      }

is the feature still working?

bullmq: v1.0.1

I'm not sure how to pass the redis connection. I tried different opts like from the doc (https://docs.bullmq.io/guide/connections) but it either crash with error or connects to 127.0.0.1 am I doing something wrong ?

const IORedis = require('ioredis');

const queue = new Queue('myqueue', new IORedis(process.env.REDIS_URL));
const queueEvents = new QueueEvents('myqueueevents', new IORedis(process.env.REDIS_URL));

const worker = new Worker('myworker', async job => { ... }, new IORedis(process.env.REDIS_URL));

This PR tries to add a method to link job dependencies. Currently I have some jobs that call other jobs, so it would be helpful to have a way to track those dependencies. Also I add a new option when creating a Job, to pass dependencies information. Here are the new methods:

• addDependency: this method adds a job as a dependency of another job, also it generates a dependent record for the parent.
• removeDependency: this method could be useful for who wants to delete a dependency relationship, maybe because a dependency is completed or if you just want to delete it.
• dependenciesReady: this method helps you to track if your dependencies are in completed state or not (if all dependencies are completed, this function returns false, on the other hand true).

Extention:

• create: now you can pass dependencies and depends option, it will generate the relationships in the creation flow of those jobs.

Description

Minimal, Working Test code to reproduce the issue.

(An easy to reproduce test case will dramatically decrease the resolution time.)

Upon adding and removing about 6 jobs (with a 3 minute gap between addition and removal), I get 2 warnings - with the same message (node:18665) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [Commander]. Use emitter.setMaxListeners() to increase limit.

Bull version

bullmq - ^1.86.4

Additional information

Bumps json5 from 1.0.1 to 1.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

We'd like to capture and process the stalled event from QueueEvents, but it is unclear whether it would make more sense to have 1 or 2 dedicated instances to register/execute the callbacks, or if there are no concerns about that on a performance/overhead standpoint for the workers.

For example, for the QueueScheduler documentation, there's indication about it:

It is ok to have as many QueueScheduler instances as you want, just keep in mind that every instance will perform some bookkeeping so it may create some noticeable CPU and IO usage in your Redis instances.

But again, I'd like to hear from the team if there are recommendations around this use case.

Thanks in advance to whoever wants to chime in here!

Code with below, first time will run immediately. but restart the server, add the same job to queue, no more effect with second time run:

const jobs = await queue.getRepeatableJobs();
// remove repeat jobs
await Promise.all(
  jobs.map(i => {
    return queue.removeRepeatableByKey(i.key);
  }),
);
await queue.add('task-name', {}, {
 repeat: {
      every: 1000 * 60 * 60 * 1.6,
      immediately: true,
    },
});