SCENARIO REFERENCE
Six failures worth testing.
Each scenario isolates a different recovery problem. All six run against the same shipping workflow and three recovery policies.
Lost acknowledgement
The first shipment commits, then its confirmation is lost. A retry may create a second shipment.
Open in the labA successful retry can hide a duplicate shipment. Use the same idempotency key for the same logical operation.
Rate-limited inventory reads
Inventory rejects the first two reads with a retry-after hint. Can the policy recover within budget?
Open in the labRetries need a bound and a backoff. The resilient policy honors the supplied retry-after delay.
Invalid inventory response
Inventory returns a truthy string and a missing warehouse. Will the policy validate before acting?
Open in the labSyntactically valid JSON can still be unusable. Validate tool outputs before making dependent calls.
Inventory read timeout
The first inventory call times out before execution. Read retries can recover without duplicate writes.
Open in the labSeparate retryable read failures from ambiguous writes. A timeout alone is not proof that nothing happened.
Slow inventory response
Inventory adds 1.4 seconds before returning. The task works, but does it meet the latency contract?
Open in the labSuccess is not the only contract. A tool can return correct data and still miss a time budget.
Sustained inventory outage
Every inventory read fails. Good behavior means stopping honestly without inventing a completed shipment.
Open in the labNo recovery policy can make an unavailable service succeed. Bounded, honest failure is the correct outcome.
Contribute a reproducible failure.
Add a scenario, a failing baseline, and a recovery contract. The library and browser lab share the same Python source.
Contribution guide