WARNING: Cluster slots configuration changed, fetching new o

Error message

WARNING: Cluster slots configuration changed, fetching new one...\n

What it means

Emitted at the top of fetchClusterSlotsConfiguration() (redis-benchmark.c:1276) when a benchmark worker thread detects that the cluster's slot-to-node mapping has changed since its last fetch (via the atomic slots_last_update timestamp set by other threads after a topology change). Because the benchmark must route each command to the correct node via the slot hash, a stale map would cause MOVED/ASK redirections and corrupt results, so it re-issues CLUSTER SLOTS against the first known node. This is an informational notice, not a failure.

Source

Thrown at src/redis-benchmark.c:1276

    return success;
}

/* Request the current cluster slots configuration by calling CLUSTER SLOTS
 * and atomically update the slots after a successful reply. */
static int fetchClusterSlotsConfiguration(client c) {
    UNUSED(c);
    int success = 1, is_fetching_slots = 0, last_update = 0;
    size_t i;
    atomicGet(config.slots_last_update, last_update);
    if (c->slots_last_update < last_update) {
        c->slots_last_update = last_update;
        return -1;
    }
    redisReply *reply = NULL;
    atomicGetIncr(config.is_fetching_slots, is_fetching_slots, 1);
    if (is_fetching_slots) return -1; //TODO: use other codes || errno ?
    atomicSet(config.is_fetching_slots, 1);
    fprintf(stderr,
            "WARNING: Cluster slots configuration changed, fetching new one...\n");
    const char *errmsg = "Failed to update cluster slots configuration";
    static dictType dtype = {
        dictSdsHash,               /* hash function */
        NULL,                      /* key dup */
        NULL,                      /* val dup */
        dictSdsKeyCompare,         /* key compare */
        NULL,                      /* key destructor */
        NULL,                      /* val destructor */
        NULL                       /* allow to expand */
    };
    /* printf("[%d] fetchClusterSlotsConfiguration\n", c->thread_id); */
    dict *masters = dictCreate(&dtype);
    redisContext *ctx = NULL;
    for (i = 0; i < (size_t) config.cluster_node_count; i++) {
        clusterNode *node = config.cluster_nodes[i];
        assert(node->ip != NULL);
        assert(node->name != NULL);

View on GitHub (pinned to 3acc0c49cf)

Solutions

If the cluster is being intentionally resharded/failover-tested, ignore this message; it indicates correct auto-refresh behavior.
Stabilize the cluster topology before benchmarking for clean numbers: finish resharding, wait for failover to settle, then re-run.
Reduce benchmark duration so it is less likely to span a topology change.
Confirm with CLUSTER INFO that cluster_state is ok and cluster_slots_assigned == 16384 before running.

Example fix

# before: benchmarking during an active reshard (frequent refresh notices)
redis-cli --cluster reshard 127.0.0.1:7000 ... &
redis-benchmark --cluster -h 127.0.0.1 -p 7000 -n 1000000

# after: stabilize first, then benchmark
redis-cli --cluster check 127.0.0.1:7000  # ensure cluster_state:ok
redis-benchmark --cluster -h 127.0.0.1 -p 7000 -n 1000000

Defensive patterns

Strategy: retry

Validate before calling

# Confirm cluster is stable (no ongoing slot migration) before running:
redis-cli -c -h $HOST -p $PORT cluster info | grep -E 'cluster_state:ok|cluster_slots_migrating:0|cluster_slots_importing:0'

Prevention

Do not run redis-benchmark during reshard, failover, or node add/remove — those mutate the slot map.
Verify `cluster_state:ok` and zero migrating/importing slots via `CLUSTER INFO` before each benchmark run.
Re-run the benchmark if topology changed; the tool refetches the config but mid-flight churn still skews results.

When it happens

Trigger: Produced only in --cluster mode at runtime when config.slots_last_update advances past the per-client c->slots_last_update, i.e. another thread already updated the global slot map after a MOVED was observed. The function then wins the atomic is_fetching_slots flag and logs the message before issuing the CLUSTER SLOTS command. It will recur each time slot ownership changes during the benchmark run.

Common situations: Running a long benchmark against a cluster that is being actively resharded, scaled out, or failed over; a cluster with unstable nodes causing frequent failover; multiple benchmark threads racing where one triggers a refresh that others pick up. Expected and benign during elasticity operations.

Related errors

AI-assisted analysis of redis/redis@3acc0c49cf (2026-08-01). Data as JSON: /data/errors/923c7c2b1d71f6e5.json. Report an issue: GitHub.