Redis "OOM command not allowed"? It's not a crash — it's your maxmemory policy

Your app logs fill with OOM command not allowed when used memory > 'maxmemory'. The instinct — restart the Redis pod — doesn't help. This isn't a container OOMKill; it's Redis's own memory policy rejecting writes.

Not a container OOM

A container OOMKill is the kernel killing the process (exit 137, cgroup limit). This is different: Redis was configured with maxmemory, hit it, and under the default noeviction policy it returns an error on every write while still serving reads. So the pod stays up, reads work, and only writes fail — the failure is silent unless you watch used_memory/maxmemory or INFO errorstats (errorstat_OOM since Redis 6.2).

The fix (a config choice, deliberately)

• Redis as a cache: set an evicting policy — allkeys-lru (evict any key) or volatile-lru (evict keys with a TTL). Note volatile-* only evicts keys that HAVE a TTL, so set TTLs or they're ineligible and you still OOM.
• Redis as a store (no data loss allowed): raise maxmemory (CONFIG SET maxmemory <bytes>) with RAM headroom for the OS + client buffers + COW, or shard across nodes / delete big keys.
• Don't flip to an evicting policy on a datastore — that silently loses data.

Snapback's redis family also covers cluster redirects (MOVED/ASK — use a cluster-aware client, don't retry the same node). Pass the error to diagnose_infra_error for the policy-vs-restart fix.