Redis Error: WRONGTYPE — Wrong Key Type

127.0.0.1:6379> SET user:42 '{"name":"Alice"}'
OK
127.0.0.1:6379> LPUSH user:42 'role:admin'
(error) WRONGTYPE Operation against a key holding the wrong kind of value

WRONGTYPE is Redis telling you “this key holds a different data type than the command expects.” Each Redis key is locked to a single type from its first write until it’s deleted. Mixing operations across types — or worse, two code paths writing different types to the same key — is the only way WRONGTYPE happens.

The single most effective preventive habit is type-suffixed key naming: user:42:profile (string), user:42:tags (set), user:42:counters (hash). The key name encodes the shape, the shape is visible at every read site, and accidental cross-type usage becomes a code-review issue rather than a runtime bug. Combined with a small TYPE check at sensitive call sites, you can eliminate WRONGTYPE almost entirely.

Why this happens

• Two code paths writing different types to the same key. One service writes a JSON string with `SET user:42 '{...}'`; another tries to push a tag with `LPUSH user:42 ...`. Both look correct in isolation but collide at runtime. WRONGTYPE is the symptom of an unmapped namespace boundary.
• Migration left old-typed keys behind. You changed the schema from `SET user:42:tags 'admin,beta'` to `SADD user:42:tags admin beta` but didn't run the migration. New code hits old keys and fires WRONGTYPE on every read.
• Cache key clash with another feature. Two unrelated features chose the same key prefix (`session:abc`). One uses HSET (hash), the other GET (string). Neither team realises until a customer hits both code paths in the same session.
• SET overwriting a complex type's key. If a feature writes `SET key value` to a key that previously held a list/hash/set, Redis allows the SET (it replaces the value entirely with a string). Subsequent commands against the old type fail. Sometimes the bug is that SET *succeeded* — the destruction is silent.
• TTL-zero key returning unexpectedly. A key that expired and was rewritten by the wrong code path may now have a different type than your reader expects. Cache stampedes after TTL expiry are a common WRONGTYPE source.

How to fix it

Fixes are ordered by likelihood. Start with the first one that matches your context.

import { createClient } from 'redis';
const redis = createClient();
await redis.connect();

async function appendTag(userId, tag) {
  const key = `user:${userId}:tags`;     // type-suffixed
  const type = await redis.type(key);
  if (type !== 'set' && type !== 'none') {
    throw new Error(`Expected set at ${key}, got ${type}`);
  }
  await redis.sAdd(key, tag);
}

-- KEYS[1] = key, ARGV = elements to SADD
redis.call('DEL', KEYS[1])
for i = 1, #ARGV do
  redis.call('SADD', KEYS[1], ARGV[i])
end
return #ARGV

import redis

r = redis.Redis()

def get_tags(user_id):
    key = f"user:{user_id}:tags"
    try:
        return r.smembers(key)
    except redis.exceptions.ResponseError as e:
        if 'WRONGTYPE' not in str(e):
            raise
        # Old format: comma-separated string. Migrate.
        raw = r.get(key)
        tags = set(raw.decode().split(',')) if raw else set()
        pipe = r.pipeline()
        pipe.delete(key)
        if tags:
            pipe.sadd(key, *tags)
        pipe.execute()
        return tags

Detection and monitoring in production

Surface WRONGTYPE as its own metric — it's almost always a bug, never a transient. A single occurrence in production warrants investigation. Tag by key prefix in your error tracker so you see clusters around specific features. Redis Slowlog and `MONITOR` can capture the offending command sequence during incidents.