Processing list.

A naive queue runs four steps. A producer pushes a job with LPUSH queue "message". A consumer takes it with RPOP queue, which removes it from Redis. The consumer then crashes during processing. The job is gone permanently — not in the queue, not finished, with nothing to recover it from.

The flaw is the RPOP. It removes the job before any work has run, so between the pop and the finish there is a window in which the job is in neither place. A deploy, an out-of-memory kill, or a power loss in that window drops the job. The window is small, but a busy queue runs the move millions of times, and small windows fire.

Instead of removing the job, atomically move it into a "processing" list. The job stays in Redis until it is explicitly removed after successful processing. The transfer is one command — RPOPLPUSH, or the modern LMOVE — so there is no instant at which the job is in neither place.

A crashed worker therefore leaves the job parked in the processing list, where it can be found and returned. The naive form removes the job and bets the worker survives; the atomic form moves the job and keeps it recoverable whether the worker survives or not. That single change — move, do not remove — is the whole pattern.

The consumer uses LMOVE (or the older RPOPLPUSH) to atomically transfer a job from the main queue to a processing queue. The one command removes the job from the right of work_queue, adds it to the left of processing:worker1, and does both atomically — no job loss is possible.

The older RPOPLPUSH source dest is the same move in fixed directions. After successful processing, remove the job from the processing queue with LREM processing:worker1 1 "message". For consumption without polling, the blocking form BLMOVE work_queue processing:worker1 RIGHT LEFT 30 waits up to 30 seconds for a job rather than returning immediately on an empty queue. The second dive walks RPOPLPUSH vs LMOVE and the blocking variant.

A job moves through three steps. Dequeue: LMOVE work_queue processing:worker1 RIGHT LEFT. Process: the application handles the job. Acknowledge: LREM processing:worker1 1 "message". If the worker crashes between the dequeue and the ack, the job remains in processing:worker1. That parked job is the seam reliability rests on: still in Redis, attributable to a worker, returnable for another attempt. Delivery is therefore at-least-once — delivered one or more times, never zero — which R3.02 makes the consumer idempotent for, and R3.03 reclaims a stalled job with. This module stops at the move.

Each worker should have its own processing queue — processing:worker1, processing:worker2. A per-worker list lets a recovery monitor attribute a parked job to the worker that holds it, and return it cleanly. The processing list is not only a buffer; it is the recovery ledger, a list of exactly the jobs currently in flight per worker. EchoMQ records the lease deadline as the in-flight set's score instead, so the score is the recovery clock and no per-worker list is needed — the third dive reads that ledger.

Each dive takes one layer of the move, in source order: the list as a queue underneath everything, the atomic transfer command that closes the gap, and the in-flight list read as the recovery ledger. Read them in order — the primitive first, the command second, the ledger third.