429 Too Many Requests error handling in Polygon RPC provider
19K reputation · 11 Jan 2021, 15:10 UTC
Goal: Graceful cancellation and timeout handling
The Polygon RPC layer signals request throttling with an HTTP 429 status and the message "Too Many Requests" once the per‑minute quota is exceeded. When a client library times out or receives a 429, the current pattern is to abort the request and surface a generic error to the caller. There is no standard mechanism for automatic retries or for propagating cancellation across nested async operations.
Unresolved design decision
Should the Polygon RPC layer expose a built‑in exponential‑backoff or retry policy for transient errors such as 429 or network timeouts, or should this responsibility remain entirely with client libraries? The lack of a documented retry strategy leads to inconsistent client behaviour and potential over‑re‑throttling.
- What criteria should the RPC layer use to decide when to retry a failed request?
- How can a retry policy be implemented without violating the provider’s rate‑limit thresholds?
- Should the RPC layer expose a configurable back‑off strategy to client libraries?
polygon