A worker consuming a Redis Stream with XREADGROUP crashed while holding entries it had not acknowledged. What happens to those entries, and how do you get them processed by a surviving worker?

## There is no automatic redelivery The single most important fact: Redis Streams do not have a visibility timeout. If a consumer reads entries and dies, those entries sit in the group's Pending Entries List forever, tagged with the dead consumer's name, and no other consumer will ever be offered them by `XREADGROUP ... >` — `>` only serves entries never delivered to the group at all. Recovery is a job your application must run. This differs from queue systems that lease messages and re-queue them after a timeout, and candidates who assume a lease model design pipelines that quietly leak work. ## Finding the abandoned entries The diagnostic query is the extended XPENDING with an idle filter: ``` XPENDING mystream mygroup IDLE 60000 - + 10 ``` Each row is `entry-id, consumer, idle-ms, delivery-count`. Idle time is measured from the last delivery or claim of that entry, so anything idle far beyond your normal processing time is either owned by a dead process or by a wedged one. `XINFO CONSUMERS mystream mygroup` gives the complementary view: a consumer whose own idle time is large and whose pending count is non-zero is almost certainly gone. ## XCLAIM: surgical transfer of ownership ``` XCLAIM mystream mygroup worker-2 60000 1712345678901-0 ``` The arguments are key, group, the *new* owner, `min-idle-time` in milliseconds, and one or more entry IDs. Redis transfers each entry only if its current idle time is at least `min-idle-time`; otherwise it is skipped and simply not returned. Because the check and the transfer happen inside one command on the server, two workers issuing the same claim concurrently cannot both succeed — the first resets idle time to zero, so the second's guard fails. That is the whole race-safety story, and it is why you never claim with `min-idle-time 0` in a competitive loop. By default XCLAIM returns the entries with their fields, so the claiming worker can process them immediately. Useful options: - `JUSTID` returns only IDs and does **not** increment the delivery counter (handy for bookkeeping sweeps that are not going to process the data). - `IDLE ms` / `TIME unix-ms` set the new idle value explicitly, e.g. to schedule a retry backoff. - `RETRYCOUNT n` overrides the delivery counter. - `FORCE` creates a PEL entry even if none exists, provided the entry is still in the stream — a repair tool, not a normal path. ## XAUTOCLAIM: the sweep you actually schedule XCLAIM requires you to know the IDs. XAUTOCLAIM (Redis 6.2+) folds the scan and the transfer into one cursor-based command: ``` XAUTOCLAIM mystream mygroup worker-2 60000 0 COUNT 50 ``` It starts at the given ID cursor (`0` for the beginning of the PEL), claims up to COUNT entries idle for at least 60s, and returns three things in Redis 7.0+: the next cursor to resume from (`0-0` when the scan wrapped), the claimed entries with their fields, and a list of IDs that were deleted from the PEL because the underlying stream entry no longer exists. That third element matters: trimming with MAXLEN can evict entries that are still pending, leaving dangling PEL records, and XAUTOCLAIM is the mechanism that reaps them. The normal deployment pattern is that every worker runs the same loop: drain its own pending history with `XREADGROUP ... STREAMS key 0`, then run one XAUTOCLAIM pass, then read new work with `>`. No leader election is needed — the min-idle-time guard makes concurrent sweeps safe, and duplicated effort is bounded. ## Choosing min-idle-time Set it well above the p99 processing time for one entry, including retries and any external call timeouts. Too low and you steal entries from healthy-but-slow workers, producing genuine concurrent double-processing. Too high and failed work sits idle for that long before anyone picks it up. A few multiples of the worst realistic job duration, or of your job timeout, is the usual framing. ## Poison entries and the delivery counter Every claim (and every redelivery) bumps the entry's delivery counter, visible in XPENDING. An entry with a counter climbing into double digits is not a transient failure — it is a message that crashes whatever touches it. Redis has no built-in dead-letter queue, so the pattern is explicit: when the counter exceeds a threshold, XADD the payload plus the failure reason to a separate dead-letter stream, then XACK the original so it leaves the PEL, and alert. Without that, a poison entry is claimed forever and can wedge a whole pipeline. ## Cleaning up dead consumers After its pending entries have been claimed away, the dead consumer name still lingers in the group. `XGROUP DELCONSUMER mystream mygroup worker-7` removes it and returns how many pending entries it still held — a non-zero return means you just discarded work, so delete only after claiming. Periodic cleanup keeps `XINFO CONSUMERS` readable in environments with churning hostnames or pod names, which is also the argument for stable, slot-based consumer names rather than random ones.