Repository: valkey-io/valkey
File: src/cluster_legacy.c (C)

Code before:
                     * theslot to its old primary. Under such circumstances, the node would undergo
                     * an election and have its config epoch increased with consensus. That said, we
                     * will still explicitly bump the config epoch here to be consistent with the
                     * existing practice.
                     * Nevertheless, there are scenarios where the source shard may have transferred slot
                     * to a different shard. In these cases, the bumping of the config epoch
                     * could result in that slot assignment getting reverted. However, we consider
                     * this as a very rare case and err on the side of being consistent with the current
                     * practice. */
                    clusterDelSlot(j);
                    clusterAddSlot(myself, j);
                    clusterBumpConfigEpochWithoutConsensus();
                    clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG | CLUSTER_TODO_UPDATE_STATE |
                                         CLUSTER_TODO_FSYNC_CONFIG);
                }
            }
        }
    }

    if (migration_source_node != NULL && first_migrated_slot != -1 && last_migrated_slot != -1) {
        serverLog(LL_NOTICE,
                  "Slot range [%d, %d] is migrated from node %.40s (%s) in shard %.40s"
                  " to node %.40s (%s) in shard %.40s.",
                  first_migrated_slot, last_migrated_slot, migration_source_node->name, migration_source_node->human_nodename,
                  migration_source_node->shard_id, sender->name, sender->human_nodename, sender->shard_id);
    }

    /* After updating the slots configuration, don't do any actual change
     * in the state of the server if a module disabled Cluster
     * keys redirections. */
    if (server.cluster_module_flags & CLUSTER_MODULE_FLAG_NO_REDIRECTION) return;

    /* Handle a special case where new_primary is not set but both sender
     * and myself own no slots and in the same shard. Set the sender as
     * the new primary if my current config epoch is lower than the
     * sender's. */
    if (!new_primary && myself->replicaof != sender && sender_slots == 0 && myself->numslots == 0 &&
        nodeEpoch(myself) < senderConfigEpoch && are_in_same_shard) {
        new_primary = sender;
    }

    /* If the shard to which this node (myself) belongs loses all of
     * its slots, this node should become a replica of the sender if
     * one of the following conditions is true:
     *
     * 1. cluster-allow-replication-migration is enabled
     * 2. all the lost slots go to the sender and the sender belongs
     *    to this node's shard
     *
     * Note that case 2 can happen in one of the following scenarios:
     * 1) we were a primary and the sender was a replica in the same

Review comment (refactor):
This log message is duplicated. Let's make sure the two copies don't diverge by moving it to a small function.

```c
static void logSlotRangeMigrated(int first, int last, clusterNode *source, clusterNode *dest) {
    ....
}

Code after:
                          j, sender->name, sender->human_nodename, sender->shard_id);
                setImportingSlotSource(j, NULL);
                /* Take over the slot ownership if I am not the owner yet*/
                if (server.cluster->slots[j] != myself) {
                    /* A primary reason why we are here is likely due to my primary crashing during the
                     * slot finalization process, leading me to become the new primary without
                     * inheriting the slot ownership, while the source shard continued and relinquished
                     * theslot to its old primary. Under such circumstances, the node would undergo
                     * an election and have its config epoch increased with consensus. That said, we
                     * will still explicitly bump the config epoch here to be consistent with the
                     * existing practice.
                     * Nevertheless, there are scenarios where the source shard may have transferred slot
                     * to a different shard. In these cases, the bumping of the config epoch
                     * could result in that slot assignment getting reverted. However, we consider
                     * this as a very rare case and err on the side of being consistent with the current
                     * practice. */
                    clusterDelSlot(j);
                    clusterAddSlot(myself, j);
                    clusterBumpConfigEpochWithoutConsensus();
                    clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG | CLUSTER_TODO_UPDATE_STATE |
                                         CLUSTER_TODO_FSYNC_CONFIG);
                }
            }
        }
    }

    if (first_migrated_slot != -1) {
        clusterLogSlotRangeMigration(first_migrated_slot, last_migrated_slot,
                                     migration_source_node, sender);
    }

    /* After updating the slots configuration, don't do any actual change
     * in the state of the server if a module disabled Cluster
     * keys redirections. */
    if (server.cluster_module_flags & CLUSTER_MODULE_FLAG_NO_REDIRECTION) return;

    /* Handle a special case where new_primary is not set but both sender
     * and myself own no slots and in the same shard. Set the sender as
     * the new primary if my current config epoch is lower than the
     * sender's. */
    if (!new_primary && myself->replicaof != sender && sender_slots == 0 && myself->numslots == 0 &&
        nodeEpoch(myself) < senderConfigEpoch && are_in_same_shard) {
        new_primary = sender;
    }

    /* If the shard to which this node (myself) belongs loses all of
     * its slots, this node should become a replica of the sender if
     * one of the following conditions is true:
     *
     * 1. cluster-allow-replication-migration is enabled
     * 2. all the lost slots go to the sender and the sender belongs