Retry audit

Find every retry in a real codebase and diagnose each one against the four weeks that got you here: safe to repeat, backed off, jittered, and survivable when ten thousand clients recover at once.

Due: 19 March 2027 · Weight: 25%

The brief#

Pick a codebase with retry logic in it and find out whether it survives its own week 4.

You have four weeks of failure modes to check against: does a retry site distinguish a read from a write, does it back off, does it jitter, and would it survive being one of ten thousand identical clients recovering at once. Most retry logic was written before anyone asked these questions, which is what makes it worth auditing rather than inventing a toy example.

What you submit#

One entry per retry site you find: where it is, which of the four failure modes it is exposed to (if any), what you would change, and what that change does to everything around it. Every fix in this course so far arrives with a limit attached. Backoff adds latency to requests that were about to succeed. An idempotency key needs storage and a client that remembers it. Jitter means no single client can state its own worst-case wait. Say which of those your fix brings with it, because an entry that stops at “add backoff” has read the site without reading what happens next. A retry site that already handles all four correctly is a legitimate finding — say so, and explain what makes it hold up.

Why correctness weighs more than coverage#

The weighting below is deliberate. A shallow audit of every retry site scores worse than a careful audit of most of them, because a wrong diagnosis sends someone to change working code. An audit that is careful but stops at the first three retry loops it finds has still missed the point.