subscribe never failed when sentinel master switched

[aahoughton]

Looking for thoughts here -- it's possible I'm mis-using a portion of the library. I've got a go program that ties two different redis instances together via pub/sub:

• Redis A, sentinels, psubscribe for published events
• Redis B, AWS elasticache, publish transformed events

.. the other day we had a sentinel failover in Redis A; the event count dropped to 0, no events were being published to B, cue disaster music. The particular redis instance we were connected to never died, but no events were being published to it after sentinel failover.

The library may well -- probably did -- receive the +switch-master notification, but that never bubbled up to me, and the existing connection was happy.

How would you handle this case? Is there an intention to bubble sentinel events up to clients in some way?

[vmihailenco]

What currently happens is that go-redis tries to close free connections to the old master. But PubSub connections are never free and therefore that connection is never closed. I think the proper fix would be to close all connections after master address is changed.

[vmihailenco]

Sentinel should be fixed in v6.5.1. Keeping this open as reminder to do something similar for Redis Cluster

[aahoughton]

Somehow I missed this when it occurred -- thank you, 6 months late.

[kjoe]

I've similar issue (should I open another?), when Redis Cluster failed beside blocking and non-blocking operations, and some master changes its state:

CLUSTERDOWN The cluster is down
MOVED 5441 x.x.x.x:yyyy

The cluster resurrects, but several connections to the old masters stays established.

[vmihailenco]

It makes sense to open new issue if you have a small program that reproduces the problem. This issue is about sentinel which is completely different software.

[github-actions]

This issue is marked stale. It will be closed in 30 days if it is not updated.