Retry transient failures

One useful idea

A retry makes another request, so it needs a reason and a limit. Catch only TransientError from the declared read policy. Authentication refusals, malformed responses and programming errors do not become more correct when repeated. Return the actual callback result; never manufacture a success-shaped fallback.

A callback is a function supplied to another function. request performs one operation; sleep receives a planned delay; log receives a controlled event. Tests pass list.append to sleep/log, recording values without waiting. A def can retain access to a list in its surrounding scope; the worked request uses len(calls) to select its next fixture outcome.

Validate policy before callbacks: caller-declared GET only, 1–5 total attempts, finite nonboolean base/max delays 0–60s and base no greater than max. Attempt one is the first request, not the first retry. After failure number attempt, use min(max_delay, base_delay * 2 ** (attempt - 1)). Honor a supported larger server wait. If that exceeds max_delay, stop rather than clamp below the server’s request. Never sleep after the last failed attempt.

Emit fresh attempt/reason/action/delay/cause events: retry or stop, planned float delay or None, and attempt_limit/delay_budget or None. Reasons are controlled categories, not raw exception text. Raise RetryExhausted on stop; request/sleep/log programming errors propagate. This bounds attempts and planned delay, not a callback’s runtime or total elapsed execution. The wrapper cannot inspect a closure to prove GET: pair it with this kit’s GET fetcher. Do not retry generation POSTs or claim universal idempotency. Jitter, cancellation and total deadlines require later production policies.

Refresh first: Declared transient HTTP failures, Narrow exception handling.

Trace a finished example

from provider_tools.core import retry_request
from provider_tools.errors import TransientError

calls, waits, events = [], [], []
def request():
    calls.append(1)
    if len(calls) < 3:
        raise TransientError("server_error")
    return {"job_id": "fresh_3", "state": "done"}

result = retry_request(request, sleep=waits.append, log=events.append)
print(len(calls), result["job_id"])
print(waits)
print([event["action"] for event in events])

The first two calls raise controlled transient failures. The callbacks record delays 0.25 and 0.5 plus two retry events. The third call returns actual data, which is passed to the caller. There is no HTTP, real sleeping or extra successful-request retry in this trace.

The finished implementation is in provider_tools/core.py. Reading it is guided practice, not independent evidence.

Change it, then build your own

One controlled change

Succeed on the second call and raise rate_limited with retry_after=1.5 on the first. Then change that wait to 3 under a 2-second delay budget. Predict request count, log action and waits.

Your independent task

Implement retry_request in practice.py. Validate the declared method, callbacks, attempt count and finite delays before invoking any callback. Catch only TransientError, preserve actual success, cap exponential backoff, honor or refuse supported server waits and log every planned retry/stop without raw context. Raise RetryExhausted when the attempt/delay budget ends; never sleep after the final failed call.

What success looks like

The build3 group passes third-attempt success, capped exhaustion, supported Retry-After, delay-budget stop, input refusal before callbacks, permanent-error propagation and sleep/log errors. Tests record waits instead of sleeping. A pure retry pass is not a live HTTP or idempotency certification.

Course help is guidance, not independent evidence. With JavaScript, opening help records guidance locally; otherwise note it in your README. Reset does not erase that history.

Repair a failed check

If there are four calls under max_attempts=3, include the initial call in the count. If the loop never ends, add explicit attempt/delay stops. If a permanent refusal becomes success, remove the broad catch/fallback. If logs contain private text, keep only declared reason/action/count fields.

NotImplementedError means a practice stub is still unfinished. Read the failing test name and the last error line. Change one behavior, rerun that build, then rerun all implemented builds.

Show it works on new inputs

Create success-on-two, always-timeout, permanent-404 and server-wait-over-budget scenarios with recorded callbacks. Show exact calls/waits/events, actual returned data and visible refusals. Explain why POST retries and total elapsed deadlines need different policies.

Self-review: name the input, result, refused case and reason. Your local test output and explanation are separate from a quiz score; this page does not certify a pass.

Keep the idea

A finite retry is a deliberate recovery policy, not permission to hide failures or repeat side effects.