redisOptsFromUrl does not set tls to true for rediss:// urls

[skylander86]

Description

When working with TLS encrypted redis connections (e.g., Elasticache), the Redis connection fails to connect because the tls attribute on the redis option during connecting is not set.

Minimal, Working Test code to reproduce the issue.

const q = new Queue("helloworld", "rediss://:password@hostname:6379/5")

console.log(q.client.status)  // this is stuck at `connect` state

Bull version

4.70

Additional information

[vpetlu]

+1
@skylander86 did you find a workaround?

[vpetlu]

+1 @skylander86 did you find a workaround?

Found a way to specify the tls flag after digging into the queue constructor:

const myFirstQueue = new Queue('my-third-queue', 'rediss://<url>',
    { redis: { tls: true, enableTLSForSentinelMode: false } }
  );

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[craigotis]

For anyone finding this, if you're on Bull 4, it's worth noting that while Bull doesn't properly handle rediss:// for TLS connections, it does spread the query parameters into the options object. Making code changes is one approach, but you can also add:

...?tls=true

To the end of your connection string, and assuming you're passing it directly into Bull (ie. not using the separate host/username/password options), it should enable TLS when calling into IORedis, and connect successfully.

[emanuelegorga]

Hey @craigotis , I am on Bull 4.9.0 and unfortunately the redis://xxxx.com?tls=true did not work out. Any idea why that might be the case? 🤔

[craigotis]

@emanuelegorga In what ways does it fail? Can you try with both rediss:// and ?tls=true?

[emanuelegorga]

It hangs when trying to enqueue the first job. The same behaviour happens locally if I purposely use an invalid host which will result in Bull not being able to connect to Redis.
I am sure about that the Redis host I am passing to the production environment is correct, so I am assuming that the only problem left can only be the TLS connection also considering that locally it works just fine when passing the valid local Redis instance.

One thing that makes me doubt about the tls=true parameter is the documentation on Redis here: https://github.com/luin/ioredis#tls-options

As I understand, the parameter is supposed to be taken and passed as option to the Redis instance, however, the documentation shows that the options related to TLS are supposed to go within an object instead of a boolean value like tls=true.

[craigotis]

@emanuelegorga You can put it in the options object if you want to parse it yourself. (Or know at that point that TLS is desired.)

Our specific issue was related to Bull not switching on TLS as a result of seeing rediss://, and so we had to modify our URL to hook into the query string parsing.

[emanuelegorga]

Understand. I feel like I am experiencing the same problem for the reasons mentioned in my previous comment although for some reason still unknown to me it is failing to connect. I appreciate your help here anyway @craigotis !

[elucidsoft]

This is what I came up with and it works perfectly. According to the ioredis docs, this is how you define tls, you just leave it empty.

 redis: {
        host: process.env.REDIS_HOST,
        port: +process.env.REDIS_PORT,
        username: process.env.REDIS_USERNAME,
        password: process.env.REDIS_PASSWORD,
        ...(process.env.REDIS_TLS === 'true' && { tls: {} }),
}