Design retries, degradation, and recovery

Map failure classes for secrets manager path openai/prod: retryable vs fatal vs needs-human. Retries need budgets, jitter, and idempotency rules aligned to dual-key window: readers accept v1+v2; revoke v1 only after emit proves zero v1 use for 30m. The chapter’s signature failure — revoke v1 while indexer still cached v1 → 401 storm — must take a deliberate branch, not a generic catch-all.

Implement the degrade/rollback/refuse behavior security engineer rotating openai/prod after contractor offboarding needs when SEC-REVOKE-EARLY-21 repeats. Prefer scoped controls (one flag, one weight, one tenant, one secret version) over fleet-wide restarts. Preserve evidence; do not delete logs to “clean the demo.”

After containment, check secret_version_share and auth_fail_rate moves in the safe direction and watch for retry amplification. Write the stop condition that ends the incident response for this lab.

Chaos note: inject only one fault class at a time and restore fixtures after. Watch for dual failures — dependency down and retry amplifier — which is how revoke v1 while indexer still cached v1 → 401 storm becomes an outage. Customer communication templates (even if only for the drill) beat silence. If you queue deferred work, define poison-message handling. Budget documents should state the maximum extra spend allowed during retries. Close the loop by linking the containment action to a dashboard panel for secret_version_share and auth_fail_rate.

Draw a state diagram for degrade modes and put it in the repo as ASCII if needed. Cap concurrent retries across the process, not only per request. Ensure cancellation propagates to downstream HTTP clients. When failing closed, choose a user-visible message that does not leak internals. Practice the single command that flips the kill switch or weight to zero. After recovery, drain or inspect deferred work before declaring green. In this chapter the product is answer API + indexer sharing provider key via versioned secrets manager, the human stakeholder is security engineer rotating openai/prod after contractor offboarding, and the incident id you design against is SEC-REVOKE-EARLY-21. Re-state the oracle in your notes — rotate to v2 → deploy → traffic on v2 → revoke v1 with audit event ROT-2026-07-30 — and keep the invariant visible: dual-key window: readers accept v1+v2; revoke v1 only after emit proves zero v1 use for 30m. Track secret_version_share and auth_fail_rate as the scoreboard. Surface under change control: secrets manager path openai/prod. If you only have forty minutes, finish the fixture for revoke v1 while indexer still cached v1 → 401 storm before polishing UI. Promotion language stays ternary: promote, hold, or roll back based on evidence, not hope.