MEDIUMQualitysmallError Handling

Retry transient failures with exponential backoff

Retry idempotent operations that fail transiently (network blips, rate limits) using exponential backoff with jitter and a max attempt cap — but never retry non-idempotent or permanent failures.

Why This Matters

Failing on the first transient error reduces reliability; naive tight-loop retries amplify outages and can cause thundering-herd overload.

Related Rules

Use Error Boundaries

Quality

HIGH

Log Errors with Context

Quality

HIGH

Never silently swallow errors

Quality

HIGH

Fail fast and handle errors at boundaries

Quality

HIGH

Catch this automatically on every PR

BeforeMerge scans your pull requests against this rule and dozens more. Get actionable feedback before code ships.

Join Waitlist Browse All Rules

Why this matters

Transient failures (timeouts, 429s, brief network drops) often succeed on retry. Exponential backoff with jitter spreads load and avoids hammering a struggling dependency. Only retry idempotent operations, and stop on permanent errors (4xx other than 429) or a max attempt count.

// Bad — tight retry loop hammers a failing service
while (true) {
  try { return await call(); } catch {}
}
 
// Good — bounded exponential backoff with jitter
for (let attempt = 0; attempt < 5; attempt++) {
  try {
    return await call();
  } catch (err) {
    if (!isTransient(err) || attempt === 4) throw err;
    const delay = 2 ** attempt * 100 + Math.random() * 100;
    await new Promise((r) => setTimeout(r, delay));
  }
}