🚨 Redis Error Guide: 'ASK <slot> <host:port>' — Cluster Redirect During Resharding

Overview

ASK is a transient redirect Redis Cluster returns while a hash slot is being migrated from one node to another during a reshard. Unlike MOVED (a permanent redirect that means “this slot now lives on that node, update your map”), ASK means “this specific key has already moved for this one request — go ask the target node this time, but do not update your cached slot map.” A correct client must issue an ASKING command to the target before retrying.

The literal errors a client or redis-cli surfaces:

(error) ASK 12182 127.0.0.1:7002

(error) MOVED 12182 127.0.0.1:7002

These appear whenever a key in a migrating slot is accessed. redis-cli -c (cluster mode) follows redirects automatically; a raw client, a library with a stale cluster map, or an app that opened a plain (non-cluster) connection will see the raw ASK/MOVED and fail the command.

Symptoms

• Application errors containing ASK <slot> <host:port> or MOVED <slot> <host:port> during a scale-out/reshard.
• Intermittent failures only for keys hashing into the slots currently being migrated.
• CLUSTER GETKEYSINSLOT shows keys still on the source; a subset already moved to the target.
• Resharding appears “stuck” — a slot stays in migrating/importing state.

redis-cli -h 127.0.0.1 -p 7000 -c GET user:42

-> Redirected to slot [12182] located at 127.0.0.1:7002
"value"

Common Root Causes

1. A reshard is in progress (expected, transient)

ASK during redis-cli --cluster reshard or --cluster rebalance is normal. It only becomes an error when the client does not handle it.

redis-cli -p 7000 CLUSTER NODES | grep -E 'migrating|importing'

5a8f... 127.0.0.1:7000 master - 0 ... connected 0-5460 [12182->-9f3c...]
9f3c... 127.0.0.1:7002 master - 0 ... connected 10923-16383 [12182-<-5a8f...]

[slot->-nodeid] = migrating (source); [slot-<-nodeid] = importing (target).

2. Client not in cluster mode / stale slot map

A client using a plain connection, or one that never refreshed its topology after a reshard, cannot follow redirects. It needs a cluster-aware driver (e.g. redis-py RedisCluster, Lettuce, ioredis cluster).

3. Migration stalled mid-slot

A CLUSTER SETSLOT was never issued after the last key moved, or a node died mid-reshard, leaving a slot permanently in migrating/importing.

4. ASKING not sent before retry on the target

The target node rejects a key it does not fully own unless the connection first sends ASKING. Clients that retry without it get MOVED/TRYAGAIN loops.

Diagnostic Workflow

Step 1: Confirm cluster health and which slots migrate

redis-cli -p 7000 CLUSTER INFO
redis-cli -p 7000 CLUSTER NODES | grep -E '\[|fail'
redis-cli -p 7000 CLUSTER SLOTS

cluster_state:ok
cluster_slots_assigned:16384

A cluster_state:fail or fewer than 16384 slots assigned means the reshard left a gap.

Step 2: Inspect the migrating slot

SLOT=12182
redis-cli -p 7000 CLUSTER GETKEYSINSLOT $SLOT 10
redis-cli -p 7000 CLUSTER COUNTKEYSINSLOT $SLOT   # keys left on source
redis-cli -p 7002 CLUSTER COUNTKEYSINSLOT $SLOT   # keys arrived on target

Step 3: Reproduce a redirect and verify client mode

redis-cli -p 7000    GET user:42   # plain: shows raw ASK/MOVED
redis-cli -p 7000 -c GET user:42   # -c: follows the redirect

If -c works but your app fails, the app’s client is not cluster-aware or has a stale map.

Step 4: Finish or roll back a stuck migration

# migrate remaining keys off the source
redis-cli -p 7000 CLUSTER GETKEYSINSLOT 12182 100
# then assign the slot to the target on both nodes
redis-cli -p 7002 CLUSTER SETSLOT 12182 NODE <target-id>
redis-cli -p 7000 CLUSTER SETSLOT 12182 NODE <target-id>
redis-cli --cluster fix 127.0.0.1:7000

redis-cli --cluster fix reconciles dangling migrating/importing states automatically.

Example Root Cause Analysis

During a scale-out, ops added node 7002 and ran redis-cli --cluster reshard to move 1000 slots. Halfway through, the app started throwing ASK 12182 127.0.0.1:7002 on ~6% of reads. The app used a plain redis.Redis client, not RedisCluster.

redis-cli -p 7000 CLUSTER NODES | grep 12182

... connected 0-5460 [12182->-9f3c...]

The slot was mid-migration and the client could not follow the redirect. Two fixes: (1) switch the app to a cluster-aware client so ASK/MOVED are handled transparently, and (2) let the reshard finish so the slot’s [migrating] marker clears. After swapping to RedisCluster and re-running the reshard to completion:

redis-cli -p 7000 CLUSTER INFO | grep cluster_state

cluster_state:ok

The redirects stopped because there were no in-flight slots and the client now refreshed its map on MOVED.

Prevention Best Practices

• Always use a cluster-aware client that implements the ASK/ASKING/MOVED protocol and refreshes its slot map on MOVED.
• Reshard during low traffic and let each slot migration complete; never kill a node mid-reshard.
• After any topology change, verify cluster_state:ok and cluster_slots_assigned:16384.
• Keep client libraries current — old drivers mishandle ASK vs MOVED.
• Automate topology recovery with redis-cli --cluster fix / --cluster check in runbooks.
• For more, see other Redis error guides.

Quick Command Reference

# Cluster health & slot ownership
redis-cli -p 7000 CLUSTER INFO
redis-cli -p 7000 CLUSTER NODES | grep -E '\[|fail'
redis-cli -p 7000 CLUSTER SLOTS

# Inspect a migrating slot
redis-cli -p 7000 CLUSTER COUNTKEYSINSLOT 12182
redis-cli -p 7000 CLUSTER GETKEYSINSLOT 12182 10

# Follow redirects manually
redis-cli -p 7000 -c GET user:42

# Repair a stuck reshard
redis-cli --cluster check 127.0.0.1:7000
redis-cli --cluster fix   127.0.0.1:7000

Conclusion

ASK <slot> <host:port> is not a failure by itself — it is Redis Cluster telling the client “this one key already moved; ask the target for it (after ASKING) but keep your map.” It becomes a user-visible error only when:

1. A reshard is in progress and the client is not cluster-aware.
2. The client holds a stale slot map and cannot follow the redirect.
3. A migration stalled, leaving a slot permanently migrating/importing.
4. The client retries the target without first sending ASKING.

Use a cluster-aware driver, let reshards finish, and reach for redis-cli --cluster fix when a slot is stuck. The [slot->-id] vs [slot-<-id] markers in CLUSTER NODES tell you exactly which side is migrating.