Marc Bachmann

The issue is most likely that there's no keepAlive configured. And for the keepalive itself we have another issue open: https://github.com/luin/ioredis/issues/1339

question is why isn't a connection abort detected? I think it should resubscribe. Sorry, will reopen that.

Could you test that with ioredis v5? most likely we don't know about the disconnect until some I/O happens. Fixing keepalive should get that working more reliably.

A fix for the keepalive landed on the 31. of march https://github.com/luin/ioredis/pull/1554 Did you run into the same issue?

The applied fix in ioredis v5.0.3 should work for all the node.js versions. The mention of 17.7 was just about another new configuration option in the socket api, but that's...

There's also a [`enableTLSForSentinelMode`](https://github.com/luin/ioredis#sentinel) option that might need to be `true`. Not sure why we don't just check the presence for `sentinelTLS`. ... it got added in https://github.com/luin/ioredis/pull/773, but there...

How many parallel requests do you expect to handle against redis? Do you have [Autopipelining](https://github.com/luin/ioredis#autopipelining) enabled? Maybe a high latency against and round trips against redis are causing issues and...

Before the implementation of the resp3 protocol handler will be started, it would be useful to spec out an api and requirements for client side invalidation. According to https://redis.io/topics/client-side-caching#two-connections-mode `RESP2`...

tcp keepalives could also fix that. But there's currently a bug with that configuration: #1339

20ms is quite low. are you sure about that? the ready check command probably times out as the initial connection and sending the command takes longer.