Error: connect ECONNREFUSED 127.0.0.1:6379 when using: new Queue('my-queue', {redis: 'redis://redis:6379'})

[stage88]

Description

I think this change here 2a29569#diff-afa7a0a70da4b0fa42349adcdb862c6f079f980b4051ca651d929290f34a29c7L280 has broken the ability to connect using:

const queue = new Queue('my-queue', {redis: 'redis://redis:6379', ...otherOptsHere});

I have upgraded from 3.22.11 to 3.26.0 and now I get Error: connect ECONNREFUSED 127.0.0.1:6379.

Anyway, I've updated my code to use:

const queue = new Queue('my-queue', 'redis://redis:6379', otherOptsHere);

Minimal, Working Test code to reproduce the issue.

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

Upgrade from 3.22.11 to 3.26.0

Bull version

3.26.0

Additional information

[F3WS]

I hit this problem using redis on heroku so I'm not sure if their solution will help you but it may, it involves adding the following tls object to the options:

const queue = new Queue('my-queue', process.env.REDIS_URL, { redis: { tls: { rejectUnauthorized: false } }, })

Refs:
https://help.heroku.com/HC0F8CUS/redis-connection-issues
https://devcenter.heroku.com/articles/heroku-redis#connecting-in-node-js

[manast]

No, the problem seems to be a fix that has actually created a breaking change, I am looking into it now.

[manast]

@stage88 actually after studying this a bit more, even though the previous version worked, it was undocumented and not really supported, i.e. sending a string with redis options attached to it, even if possible to do with javascript it is not a good pattern. I could not find any such example in Bull's documentation either, so I am going to close this issue now.

[stage88]

All good thanks @manast, it was an easy fix. I think my opts where leftover when I migrated from Kue.