Stage 8 · L37

Retry only safe failures within one budget

Core · original Session 8

A retry repeats one operation, so first decide whether repeating it is safe. This gateway retries an idempotent read-only GET. It does not reuse that policy for creating reservations, charging money or sending mail. Those writes need their own idempotency/delivery design rather than an automatic retry loop.

The budget is one logical lookup with at most three HTTP attempts. Transient network/timeouts and provider502/503/504 may receive another attempt while budget remains. Provider429 receives no immediate retry, and500 is an unexpected provider response under this classroom contract. Provider404 is a reachable missing observation and is not retried;400/401/403 are nonretry integration rejection. Invalid200 payload and unexpected protocol responses fail safely rather than being retried as if all data problems were temporary.

Backoff consumes the same total deadline. The current checkpoint uses short bounded teaching delays so deterministic tests remain fast; it does not claim a production jitter or comprehensive Retry-After policy. A provider's very long suggested delay must never escape a caller's end-to-end budget. A real integration should specify bounded header handling and retry jitter for its own contract.

One fixture returns503,503,200: logical_lookups is1 and attempts is3. Counting three attempts as three user operations would inflate business demand. Conversely, a breaker-open rejection is a logical lookup with zero outbound attempts. Stage09 adds per-lookup structured counters so concurrency cannot make subtraction of global totals look like a request-local count.

When attempts exhaust, the breaker sees one failed logical operation. It does not trip three times for one caller's retry loop. No fallback invents availability=True or commits a rental. The caller receives a bounded unavailable/error outcome while local stored facts remain authoritative.

Session08 explicitly does not immediately retry429. This revision now preserves that policy: one attempt ends with local503 provider_rate_limited even if Retry-After is present. That header may require provider-specific future scheduling outside the short request budget, which is not implemented. No short teaching backoff is applied to429.

Response classification:
404: reachable missing record; no retry
429:503 provider_rate_limited; one attempt; no immediate retry
502/503/504: bounded safe GET retry inside remaining budget
400/401/403: nonretryable integration rejection
Malformed payload/protocol: reject, do not invent fallback success.

The429 ends this lookup after one attempt with503; no immediate retry or short sleep occurs, regardless of Retry-After. A provider-specific later scheduling/rate-limit policy is unimplemented. Safe transient GET retries share the one remaining budget and have one owner. Two503s then200 can succeed on attempt3; retries do not reset the budget or justify replaying a write.