How to reproduce PartitionSelectorException?

[KimTaehee]

Questions

First, I appreciate you keeping Lettuce active.
I faced PartitionSelectorException during manual CLUSTER FAILOVER on my production environment. So I tried to reproduce the exception but failed.
Any feedback or ideas would be very helpful.

My questions are:

1. Is there a scenario where PartitionSelectorException might occur when running the CLUSTER FAILOVER command manually? I guess it is, but I couldn't find it.
2. As far as I understand, I don't expect to get a PartitionSelectorException if the cluster is stable and Lettuce has refreshed the topology periodically or adaptively. If so, is there a possible way to catch and retry it? (e.g.: blocks adaptive refresh and retries the command after that)

Environment

• Lettuce version(s): 5.2.2.RELEASE
• Redis version: 3.2.12 cluster mode

What I already checked:

1. Cannot determine a partition for slot #2252 (comment)
2. https://groups.google.com/g/lettuce-redis-client-users/c/AFF00Ch6x0s/m/Y6AySSWRAgAJ
3. PartitionSelectorException during refresh of Partitions #2178 // Only for 6.2.0.RELEASE

[mp911de]

PartitionSelectorException happens if there is no read or write node for a hash slot. That is, if there is no master currently serving a slot or, if the selection wants to send a command towards a replica, that there is no replica available for the slot.

You can reproduce the exception by configuring a cluster that doesn't cover all hash slots and then issuing a command against a hash slot that has no master for it.

[jingke]

any enhancement for this, I found during client setup if the redis cluster is not ready and then following the write/read command will be failure, but my question is why the topology refresh could fix this? To refresh the partitions?

[tishun]

Hey @jingke ,

any enhancement for this, I found during client setup if the redis cluster is not ready and then following the write/read command will be failure

What enhancement would you like to have done here? Can you elaborate more?

What @mp911de explained above is that - in certain cases, such as when there is no server / node handling a specific slot range - the driver fails as it does not know how to proceed and where to route the command.

Depending on the scenario you might implement different solutions. For example the client app might attempt to verify the state of the system and only start sending requests when the cluster is up. These options are specific to the application, system design and deployment model you have so there is no one-implementation-fits-all solution.

In your case - assuming you have a distributed application how do the different components verify the health of the system?

my question is why the topology refresh could fix this? To refresh the partitions?

Yes, you would eventually get the node that would serve this slot range.