Retry is a delayed job.

The delayed-queue source puts the move plainly: “If a task fails, reschedule it with a delay … Track retry counts in the task data to implement exponential backoff or maximum retry limits.” A retry is not a new mechanism. It is a re-schedule: read the attempt count, compute a delay, and ZADD the job back onto the schedule set at now + delay. The promotion sweep that already moves due delayed jobs back to pending moves the retry too.

The attempt count is the input the formula needs. In the real bus it is the attempts field on the job row — the same fencing token a claim mints with HINCRBY — so the retry path reads the attempt that has failed and prices the next delay from it. One structure carries both the first-time delayed job and every retry.

Exponential backoff doubles the wait each attempt: delay = base × 2^(attempts-1). Attempt 1 waits base; attempt 2 waits 2 × base; attempt 3 waits 4 × base. The curve climbs fast, so a dependency that is down gets longer breathing room — and a clamp (cap) holds the curve at a ceiling so a stubborn job does not schedule itself years out.

Choose a base and an attempt below to compute the delay. The readout names the literal value EchoMQ.Backoff.delay_ms/2 returns and whether the cap was reached.

When many jobs fail at the same moment — a dependency blinks — a fixed backoff schedules every retry for the same future instant. They re-fire together: the thundering herd, a second spike on a service that is already struggling. Jitter spreads them. A jittered delay is a random value bounded by the backoff delay, so a cohort that failed together re-fires across a window instead of in one spike.

In the real bus jitter is a policy wrapper: {:jitter, inner}. It computes the inner policy's delay, then returns a uniform random value in 0..inner_delay — the full-jitter form. The randomness is the point; the inner delay is its bound. The second dive runs the herd both ways.

Three dives: the formula and its clamp, the herd and the jitter that breaks it, and the schedule-set reuse that adds no new structure.

A retry adds no key and no script of its own. EchoMQ.Jobs.retry/7 is handed the literal delay_ms from EchoMQ.Backoff, reads the row's attempts, and — under the max-attempts ceiling — ZADDs the job onto the schedule set at now + delay_ms on the server clock. EchoMQ.Jobs.promote/3 then ZRANGEBYSCOREs the due range and moves those jobs back to pending. That is exactly the delayed-queue machinery from R4.01: the schedule set is the sorted set, the score is the fire-time, the promotion is the sweep.

A retry curve cannot climb forever. retry/7 carries a max_attempts argument; when the row's attempts has reached it, the job is not re-scheduled — its state is set to dead and it lands on the morgue set instead. A retry is bounded by both a ceiling on the delay (the cap) and a ceiling on the count (max attempts).