## TL;DR
Redis refuses writes because it hit `maxmemory`, almost always from keys written without TTLs or an eviction policy of `noeviction`. Set an eviction policy that matches your cache semantics (usually `allkeys-lru`), add TTLs to cache keys, and find the biggest keys to trim.

```text
redis OOM command not allowed when used memory > maxmemory
```

## Use this when
- Redis writes fail with the OOM error
- Memory climbs monotonically until writes stop
- An agent caches aggressively with no expiry

## Not for this skill when
- Clients cant connect (thats network or auth)
- Commands are slow (thats big keys or blocking ops)
- Replicas lag (thats replication)

## Steps

1. Confirm memory pressure and the current policy:

```bash
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human"
redis-cli CONFIG GET maxmemory-policy
```
Expected output: used_memory near maxmemory, and the policy (often `noeviction`, which refuses writes instead of evicting).

2. Set an eviction policy that fits a cache:

```bash
redis-cli CONFIG SET maxmemory-policy allkeys-lru
```
Expected output: `OK`. With `allkeys-lru`, Redis evicts the least-recently-used keys to make room instead of failing writes. Persist it in redis.conf so a restart doesnt revert it.

3. Find the biggest keys and check for missing TTLs:

```bash
redis-cli --bigkeys
redis-cli INFO keyspace
```
Expected output: the largest keys by type. If `--bigkeys` shows giant hashes or sets with no TTL, those are your leak.

4. Add TTLs where the agent forgot them:

```python
# set with expiry instead of bare set
r.setex(cache_key, 3600, value)
```
Expected output: keys expire after an hour and memory stabilizes. Audit every `set` call in the caching layer for a TTL.

## Variant phrasings

### OOM on a queue (list) workload
Lists used as queues with noeviction fill up and then refuse pushes. Either consume faster, cap the list length, or switch the policy.

### memory keeps growing after setting a policy
The policy only evicts when maxmemory is hit and only for eligible keys. Keys with no eviction candidacy (volatile-* policies plus persistent keys) still accumulate.

## Why it happens
Redis is an in-memory store with a configured ceiling. `noeviction` (the default) protects existing data by refusing new writes, which is correct for a primary store but wrong for a cache. Agent caching code typically calls `set` without expiry, so every cached value lives forever and the ceiling arrives as a surprise.

## Edge cases
- `allkeys-lru` evicts any key, including ones your app treats as permanent; use `volatile-lru` plus TTLs if some keys must never be evicted.
- Eviction is approximate LRU; with `maxmemory-samples` at default 5, the "least used" choice is sampled, not exact.
- On Redis Cluster, maxmemory is per node; one hot node can OOM while the cluster looks healthy overall.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7OYPFeSKdmbNpO12zktZVA