v2 P3: Built-in retry & rate-limit handling
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 36
- Forks
- 7
- Avg merge
- 4m
- Merged PRs (30d)
- 2
Description
Part of the v2 roadmap (pillar P3 — depends on P1).
429s and 5xx responses are currently surfaced immediately as exceptions. v2 should back off and retry automatically, on both clients, before giving up.
Scope
- Respect Monzo's
Retry-Afterheader on 429; exponential backoff with jitter on 5xx. - On for both
AuthenticationandAsyncAuthenticationby default, with a kwarg to disable and fall back to today's immediate-raise behaviour. - Built as an httpx transport, not a per-call wrapper — depends on #156 (P1).
Open question: concrete max-retry count and backoff ceiling still need deciding.
Breaking: yes (default network-call timing/behaviour changes)
Effort: M
Phase: beta
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the Authentication and AsyncAuthentication clients and the work in #156, then identify how an httpx transport can apply shared retry behavior. Define the concrete maximum retry count and backoff ceiling before implementation. Done means both clients retry 429 and 5xx responses by default, honor Retry-After for 429s, support disabling retries, and preserve immediate-raise behavior when disabled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100