If a cluster node is set as the new owner of a slot without first setting it to IMPORTING, the new owner doesn't bump the epoch and broadcast pong to the other nodes. This leads to inconsistent view regarding the slot ownership.
I discovered this while playing with the test "slot migration is valid from primary to another primary" in 15-cluster-slots.tcl (test case added in #10277, but that's not the source of the this inconsistency).
The test simply moves slot x from node a to b by sending CLUSTER SLOT x NODE b to a and b (the old and the new owner). The rest of the nodes in the cluster never get informed, so they still think a is the owner.
Even when b later sends cluster ping-pong to other nodes, b's slot ownership is ignored because b doesn't have the highest epoch in the cluster. (I added printouts to confirm that this is happening.)
Expected behavior
The cluster should stabilize and eventually settle with a consistent view of the slot ownership.
Additional information
Idea: The new owner could bump epoch and broadcast pong, even if it wasn't set as IMPORTING the slot. However, that doesn't solve all possible inconsistencies.
It seems to be easy to create inconsistencies and redirect loops by letting the owner of a slot believe that another slot is the new owner, e.g. by sending SETSLOT x NODE b to node a and not sending anything to node b.
Comment From: madolson
For what it's worth, SETSLOT is supposed to allow you to wedge the cluster into an inconsistent state. Since there is no backing consistency system, if the cluster is divergent you should be able to force it into whatever state you want.
Comment From: zuiderkwast
OK, thx @madolson.... If it's intentional, I guess we can close this issue.
I can add MIGRATING and IMPORTING commands to the test case, to make the test case more of an example of recommended use.