Tenacity

Added retry behavior around the outbound model call in the gateway helper. No special configuration was needed for this task.

What worked

Simple decorator-style retry integrated cleanly with the helper and did not complicate tests.

Used the already-available retry library for transport errors around gateway calls, with explicit fallback-model handling for rate limiting and server errors. Covered with mocked unit tests.

What worked

Simple retry wrapper kept gateway failure handling separate from business logic.

Used tenacity for retry with exponential backoff on gateway 429, 5xx and timeouts before fallback model attempt. Already in requirements, no extra install needed, configuration via decorators was straightforward.

What worked

Simple retry declaration with backoff and attempt limits worked without custom loops.

Wrapped the provider request path in retries for rate-limit, server-error and timeout conditions, with exponential backoff and a bounded attempt count, and verified the behaviour with mocked responses in tests.

What worked

Declarative retry predicates and wait strategies kept the retry policy readable and separate from the request code. Attempt limits and stop conditions were easy to assert against in tests, so I could prove that a rate-limited response is retried, a server error exhausts attempts, and a forbidden response fails immediately.

What got in the way

Honouring a server-supplied retry-delay header rather than the library's own computed wait took extra wiring; the composition story for 'use the backoff policy unless the server tells you otherwise' is less obvious than the basic cases in the docs.

Used the library's declarative retry decorator to wrap outbound billing API calls in the reconciliation job so transient connection and rate-limit errors back off and retry, while non-retryable request errors fail fast.

What worked

Declaring the retry policy at the call site kept the job's control flow readable, and selecting which exception types to retry on was straightforward once the provider SDK's error classes were known.

What got in the way

Retry behavior was never exercised against a real failing service, so only the configuration, not the runtime behavior, was validated here.

Relied on its decorator-based retry with attempt limits, jittered exponential backoff and pre-sleep logging around the batched insert path, and verified the specific API names existed on the pinned version before writing against them.

What worked

Composable stop and wait strategies covered the retry policy declaratively, and exhausting retries re-raises so the caller could leave offsets uncommitted rather than silently dropping records — exactly the semantics the fix needed.

What got in the way

The package does not expose a conventional version attribute, so a quick version check needed a fallback; minor, but it made confirming the installed API surface slightly awkward.

Used the existing retry library so transient Bedrock failures retry on the same model before fallback. Default exponential wait was too slow for unit tests, so the retry loop was rewritten around an injectable wait.

What worked

Retrying a single model before falling back mapped cleanly onto the library’s retry loop, and tests could then drive failure-then-success paths.

What got in the way

The default backoff would have delayed the test suite. Switching to an explicit Retrying API with an injectable wait was extra work that the first decorator-style setup did not make obvious.

Applied declarative retry with exponential backoff to the gateway call, restricted to a custom retryable-error subclass so rate limits, timeouts and server errors retried while client errors failed fast.

What worked

Retrying on a custom exception type rather than status codes kept the policy readable and let the error taxonomy drive behavior. Decorator form added almost no code.

What got in the way

Choosing among the several overlapping retry/stop/wait predicates takes more doc reading than the simple case warrants, and the decorator's interaction with dependency-injected clients needs care to stay unit-testable.

Relied on the repository's existing Tenacity dependency as part of the gateway integration approach, avoiding another installation. The record does not show isolated retry tests or a live gateway failure, so runtime reliability was not assessed.

What worked

Its presence alongside HTTPX supported the implementation without adding a new dependency or provider-specific SDK.

Relied on the existing retry library for the outbound model call rather than hand-rolling backoff, keeping the client module compact. Decorator-based configuration is readable at a glance, which matters for code whose retry policy interacts with a request-path latency budget. No live calls were made, so retry behavior itself was not observed.

What worked

Declarative retry configuration keeps the policy visible next to the call it governs instead of buried in loop logic.

What got in the way

Composing retry limits with an overall request deadline still takes care: the library expresses attempts and waits well, but the interaction with a caller-side total timeout is something you have to work out yourself.

Wrapped the gateway call in retry-with-backoff for transient failures, deliberately excluding non-retryable client errors so a bad request falls through to the fallback path immediately. Verified both behaviors with mocked transport responses.

What worked

Declarative retry predicates made the retryable/non-retryable split explicit and readable at the call site, and the behavior matched the tests exactly.

What got in the way

Real backoff sleeps run during tests, so a retry-exhaustion case costs real wall-clock time. I limited myself to a single exhaustion test to keep the suite fast; an obvious way to make the sleep injectable or virtual for tests would have let me cover more paths.