Is renewSlotCache necessary when received MOVED about jedis HOT 3 OPEN

We cannot fully adopt your suggestion because - i) Current implementation is based on Redis' proposed algorithm. ii) Usually MOVED happens to a large number of slots once; so renewing all is the faster way to update.

But I understand that for some users it might make more sense to renew slots one by one per MOVED. So we'll consider a PR that'll allow users to set a flag/config/param to update one slot (in slot cache) per MOVED instead of updating all slots.

from jedis.

We cannot fully adopt your suggestion because - i) Current implementation is based on Redis' proposed algorithm. ii) Usually MOVED happens to a large number of slots once; so renewing all is the faster way to update.

But I understand that for some users it might make more sense to renew slots one by one per MOVED. So we'll consider a PR that'll allow users to set a flag/config/param to update one slot (in slot cache) per MOVED instead of updating all slots.

How about compare with previos cluster topology?
If MOVED to a new master, just change slot owner without renewSlotCache.
If MOVED to slot owner's slave, maybe failover happened, set all slots of the shard to new master or just renewSlotCache which is more safe.
Otherwise, call renewSlotCache.

from jedis.

If MOVED to slot owner's slave, maybe failover happened, ...

"Maybe".
Maybe not.
What if the cluster is reconfigured where a replica (slave) is promoted to master with half of the slots?
Should a client library "guess" or fetch the information and use it?
To me, it's undoubtedly the later option.

If ..., just change slot owner without renewSlotCache.

Almost as I said in my previous comment.

from jedis.