Story

Hi HN,

I've been working on redress, a failure-policy library for Python services. It treats retries, circuit breakers, and stop conditions as coordinated responses to classified failure, rather than independent wrappers. The goal is to make failure behavior explicit, bounded, and observable across a codebase.

I kept running into the same problem in distributed systems and data pipelines I worked on. Retry logic grows organically at call sites and circuit breakers live somewhere else entirely. The semantics start drifting and bounds get inconsistent. Answering basic questions like "why did this operation stop" becomes needlessly difficult.

With redress's policy model, instead of asking "should we retry" I wanted to start with "what kind of failure is this?" (rate limit, server error, transient,etc) and then let a single policy decide how to respond. Retry with class-specific behavior, fail fast, open a circuit, etc.

I put together a short, runnable demo that shows this end-to-end using httpx: - result-based classification (HTTP 429 + Retry-After vs 5xx) - per-class retry strategies - bounded retries - circuit breaker coordination - explicit stop reasons and per-attempt timelines

The demo runs locally (no external services): https://github.com/aponysus/redress/blob/main/docs/snippets/...

Project: https://github.com/aponysus/redress Docs: https://aponysus.github.io/redress/

This is definitely not for simple use cases. Tenacity or hand-spun retry loops would be far better for such needs. This is intended for complex systems that need deterministic envelopes, explicit bounds, and observability hooks.

I'd appreciate any feedback.