Timeouts, Retries and Idempotency

// fetch has no default timeout. A hung connection waits forever.
const res = await fetch(url, { signal: AbortSignal.timeout(10_000) })

// Combining a timeout with user cancellation
const ctrl = new AbortController()
const signal = AbortSignal.any([ctrl.signal, AbortSignal.timeout(10_000)])

# Server side, calling anything else
async with httpx.AsyncClient(timeout=httpx.Timeout(5.0, connect=2.0)) as c:
    r = await c.get(url)

# And a database statement timeout, so one bad query cannot pin a
# connection for minutes
SET statement_timeout = '5s';

// Budget them downwards through the stack. If the browser waits 10s,
// the API must give up before that, and its database calls before
// that again — otherwise the user sees a timeout while work is still
// running and consuming resources.
//   browser 10s > API 8s > outbound HTTP 5s > query 3s

// Pick the number from the p99, not from a round figure: a timeout
// below your real latency turns a slow endpoint into a broken one.

// Safe to retry: GET, HEAD, PUT, DELETE (idempotent by definition)
// Retry on: a network error, 408, 429, 502, 503, 504
// NEVER retry: 400, 401, 403, 404, 422 — the answer will not change
// POST: only with an idempotency key

async function retrying(fn, { attempts = 3 } = {}) {
  for (let i = 0; i < attempts; i++) {
    try { return await fn() }
    catch (e) {
      if (!isRetryable(e) || i === attempts - 1) throw e
      const base = Math.min(1000 * 2 ** i, 8000)
      await sleep(base + Math.random() * 300)     // jitter
    }
  }
}

// Jitter matters more than it sounds: without it, every client that
// failed at the same moment retries at the same moment, and the
// backend that was recovering is knocked over again.

// Honour Retry-After when the server sends it — on a 429 it is not
// advice, it is the rate limiter telling you exactly when to return.

// And stop retrying a service that is clearly down. A circuit
// breaker — open after N consecutive failures, half-open after a
// cooldown — protects both sides. TanStack Query gives you the
// client half of this with retry and retryDelay options.

// Client generates a key per logical operation — NOT per attempt
const key = crypto.randomUUID()
await api('/payments', {
  method: 'POST',
  headers: { 'Idempotency-Key': key },
  body: JSON.stringify({ amount: 49900 }),
})
// Retrying reuses the same key. That is the entire mechanism.

# Server: first request does the work and stores the response;
# a repeat returns the stored one without re-executing.
@router.post("/payments")
async def create(body: PaymentIn, idempotency_key: str = Header(...)):
    existing = await db.get_idempotent(idempotency_key)
    if existing:
        return existing.response                 # same result, no double charge

    async with db.transaction():
        # reserve the key inside the transaction, or two concurrent
        # requests both see "no existing" and both charge
        await db.reserve_idempotency(idempotency_key)
        result = await charge(body)
        await db.save_idempotent(idempotency_key, result)
    return result

// Keys expire — 24 hours is typical.
// Also guard the same operation at the UI level: disable the button
// while the request is in flight. Defence in depth, because the key
// only helps if the client actually reuses it.