🚨 Redis Error Guide: 'ERR no such key' — Fix RENAME, MOVE, and OBJECT on Missing Keys

Overview

Redis returns no such key when a command that requires the key to exist is run against a key that is absent. Commands like RENAME, RENAMENX, MOVE, OBJECT ENCODING, DUMP, and PERSIST do not silently no-op — if the source key is missing, they error.

The literal error clients receive:

(error) ERR no such key

Unlike GET (which returns nil for a missing key), these commands treat absence as an error. The real question is why the key is gone: it expired, it was evicted under memory pressure, it lives in a different logical DB, or in a cluster it is on a node you did not query.

Symptoms

• RENAME/MOVE/OBJECT/DUMP fails while EXISTS returns 0 for the key.
• Intermittent — the key is present sometimes and gone other times (TTL/eviction).
• Works against one node/DB but not another (cluster or wrong SELECT).

redis-cli RENAME session:old session:new

(error) ERR no such key

redis-cli EXISTS session:old

(integer) 0

Common Root Causes

1. The key expired

A TTL elapsed between the last write and the RENAME/OBJECT call.

redis-cli TTL session:old

(integer) -2       # -2 means the key does not exist

2. The key was evicted under memory pressure

With an allkeys-* eviction policy, the key was dropped to make room.

redis-cli INFO stats | grep evicted_keys

evicted_keys:184023

3. Wrong logical database

The key is in db0 but the client is on db3 (or vice versa).

redis-cli -n 0 EXISTS session:old   # (integer) 1
redis-cli -n 3 EXISTS session:old   # (integer) 0

4. Cluster: key lives on another node

In cluster mode the key hashes to a slot owned by a different node than the one you queried.

redis-cli -c -p 7000 CLUSTER KEYSLOT session:old

How to diagnose

Step 1: Confirm the key really is absent

redis-cli EXISTS session:old
redis-cli TTL session:old

EXISTS 0 and TTL -2 both confirm the key is gone.

Step 2: Determine whether it expired or was evicted

redis-cli INFO stats | grep -E 'expired_keys|evicted_keys'

Rising evicted_keys points to memory pressure; a set TTL points to expiry.

Step 3: Check you are on the right database

redis-cli INFO keyspace       # shows which DBs hold keys
redis-cli -n 0 EXISTS session:old

Step 4: In a cluster, follow the slot

redis-cli -c -p 7000 GET session:old   # -c follows MOVED redirects
redis-cli CLUSTER KEYSLOT session:old

Fixes

Check existence before the exact-key command

redis-cli EXISTS session:old && redis-cli RENAME session:old session:new

Or use RENAMENX and handle the 0/error return in code rather than assuming success.

Target the correct database

redis-cli -n 0 RENAME session:old session:new

Give keys enough TTL, or remove eviction surprises

If the key must survive, extend its TTL or store it on an instance that is not under allkeys-lru pressure.

redis-cli EXPIRE session:old 3600

In a cluster, use a cluster-aware client

redis-cli -c -p 7000 RENAME session:old session:new

Note RENAME across two keys still requires both keys to hash to the same slot — use hash tags like {user1}:old / {user1}:new.

What to watch out for

• GET returns nil for a missing key, but RENAME/OBJECT/DUMP/PERSIST raise no such key. Don’t assume all commands treat absence the same way.
• TTL returns -2 for a missing key and -1 for a key with no expiry — distinguish the two.
• In cluster mode, RENAME/SMOVE/COPY require both keys in the same slot or you get CROSSSLOT, not no such key.
• Eviction is silent; only INFO stats (evicted_keys) reveals it after the fact. Alert on it.

Related

• Redis Error: ‘OOM command not allowed when used memory > maxmemory’
• Redis Error: ‘CROSSSLOT Keys in request do not hash to the same slot’
• Redis Error: ‘WRONGTYPE Operation against a key holding the wrong kind of value’

Paste the failing command into the free incident assistant, and browse more Redis guides.