feat(queue): handle redis url starting with rediss scheme by specifying tls as empty object

[Otanikotani]

We believe this is a potential in house fix for https://github.com/OptimalBits/bull/issues/2325 . Our setup:

• AWS Elasticache 6.2.6 with TLS enabled.
• Nestjs app that uses bull.
• The configuration for Redis is set through a Redis url which looks like: rediss://:banana@master.use1.cache.amazonaws.com?tls=true

We have been experiencing intermittent

Error: Connection is closed.
    at close (/usr/src/app/node_modules/ioredis/built/redis/event_handler.js:189:25)
    at TLSSocket.<anonymous> (/usr/src/app/node_modules/ioredis/built/redis/event_handler.js:156:20)
    at Object.onceWrapper (node:events:634:26)
    at TLSSocket.emit (node:events:531:35)
    at TLSSocket.emit (/usr/src/app/node_modules/dd-trace/packages/datadog-instrumentations/src/net.js:69:25)
    at node:net:339:12
    at TCP.done (node:_tls_wrap:657:7)
    at TCP.callbackTrampoline (node:internal/async_hooks:130:17)

We think that the following issue is somehow related: https://github.com/redis/ioredis/issues/1628. We do not experience "Connection is closed." error if we disable TLS on our Elasticache Redis.

When we switched from using a Redis url to providing Redis options like this:

const opts: RedisOptions = {
      host: this.host,
      port: this.port,
      db: this.database,
      password: this.password,
};
if (this.scheme === 'rediss') {
      opts.tls = {};
}
if (this.username) {
      opts.username = this.username;
}
return opts;

the error went away. So we would like to bring the same logic to the getOptsFromUrl function. If the protocol is rediss then the tls: {} is added to the Redis options.

Kudos to: @hype08 @joshgrift

[mbackermann]

We should definitely have this option going forward