bullmq: Queue error: Connection is closed.
Hey there,
we we are adding jobs to a queue within an expressjs application. Therefore we are initializing the queue at startup.
Now we see almost regularly console log messages Connection is closed. If adding an Error-Listener this error is catched (stating the same error message). Nevertheless new jobs can be added to the queue successfully.
The same behaviour can be seen in a plain NodeJS application. This error does not appear for workers.
My question is: how to deal with this error. Adding an error listener with queue.on(“error”,…) and supressing log messages feels quite bad. Can anyone give me a hint to search for the cause? Is this a bug in BullMQ or an issue in IORedis?
Thank you so much and best regards!
import { Queue } from 'bullmq'
(async () => {
const queue = new Queue("test-queue",
{
connection: {
host: "host",
port: 6380,
password: "topsecret",
tls: { servername: "host" },
},
});
queue.on("error", (error: Error) => {
// Suppressing it feels bad...
// console.log(error.message);
});
})();
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 6
- Comments: 17 (6 by maintainers)
Commits related to this issue
- fix(close): emit ioredis:close event instead of error (#1251) fixes #1231 — committed to taskforcesh/bullmq by roggervalf 2 years ago
- chore(release): 1.83.2 [skip ci] ## [1.83.2](https://github.com/taskforcesh/bullmq/compare/v1.83.1...v1.83.2) (2022-05-24) ### Bug Fixes * **close:** emit ioredis:close event instead of error ([#12... — committed to taskforcesh/bullmq by semantic-release-bot 2 years ago
same issue for me, local redis works, managed redis on digitalocean doesn’t.
the console is spammed with these error messages since 1.80.4 as far as I can tell, since reverting to 1.80.3 resulted in 0 of these error messages thereafter and bumping the version up to 1.80.4 instantly caused these errors to reappear.
full stack trace for anything after 1.80.3:
the commit/change that I assume causes this issue can be found here.
thanks for taking the time and adressing the issue.
I can confirm this occures first with 1.80.4 but not with 1.80.3
@manast I see you likely found the cause and fixed it, great! thanks 🙏
edit: pr is from @roggervalf so kudos there! 😉
We are seeing this error too, using Heroku-Redis. Noticed it a couple of weeks ago, and we haven’t changed anything in our implementation.
A log snippet:
The behavior occurs with both the Standard C0 (256 connections) and Premium P1 (7500 connections) tiers. The Redis instance is exclusively used for BullMQ.