Unhandled ETIMEDOUT error event is thrown even without listeners

[Erreichl]

Hello there, we are using bull(mq)/redis for our queues. Recently our redis seems to be unreachable every other day for a few seconds. Now we are trying to prevent this error to crash our application. If I understood the documentation correctly, the error events should be emitted silently and not cause any harm.

We get these errors

[ioredis] Unhandled error event: Error: connect ETIMEDOUT
at processTimers (internal/timers.js:497:7)
at Socket.EventEmitter.emit (domain.js:483:12)
at Socket.emit (events.js:314:20)
at Object.onceWrapper (events.js:420:28)
at Socket.<anonymous> (/app/node_modules/ioredis/built/redis/index.js:317:37)
at processTimers (internal/timers.js:497:7)

Error: connect ETIMEDOUT
at Socket.<anonymous> (/app/node_modules/ioredis/built/redis/index.js:317:37)
at Socket.emit (events.js:314:20)
at Object.onceWrapper (events.js:420:28)
at Socket._onTimeout (net.js:483:8)
at RedisConnection.emit (events.js:314:20)

Until now, we were calling our redis just with the connection url.

new Redis(url)

After some investigation we tried to use reconnectOnError from this documentation. But we still get the error from above.

new Redis(url, {
  reconnectOnError (err) {
    const targetError = 'ETIMEDOUT'
    if (err.message.includes(targetError)) {
      return 1 
    }
  }
})

4.27.7 - is our ioredis version 12.19 - is our node version

Are we missing something? Is this a known issue? How can we prevent this error?

Thanks in advance Eric

[luin]

It's caused by timeouts at the connecting stage. You can try to increase the connectTimeout option. ioredis does emit errors silently. Isn't that what you've encountered?

[psnehanshu]

ioredis does emit errors silently. Isn't that what you've encountered?

No, I have noticed ETIMEDOUT crashes the whole process. I am on v5.3.1

[tiagosiebler]

ioredis does emit errors silently. Isn't that what you've encountered?

No, I have noticed ETIMEDOUT crashes the whole process. I am on v5.3.1

Currently investigating the same issue, did you find a way to safely handle this? @pSnehanshu

[psnehanshu]

It has been a while, but I think just attaching listeners to error events fixed it.

[tiagosiebler]

It has been a while, but I think just attaching listeners to error events fixed it.

Thanks for the reply! Found that too, seems to work nicely

[junoriosity]

@pSnehanshu Could you give a code example how to solve it?