RPC error HTTP 429 / -32005: eth_getLogs capacity exhausted on BSC
Last updated:
At a glance
| Property | Value |
|---|---|
| Applies to | Every network, HTTP and WebSocket |
| HTTP status | 429, with Retry-After: 2 |
| JSON-RPC code | -32005 |
| Applies to | eth_getLogs on blocks older than about 9,000 |
| Your plan's RPS | Not the cause |
| Retryable | Yes, with a narrower range |
Cause
Triport has no BSC nodes of its own, so blocks older than about 9,000 are served by shared archive sources. When none of them can take a request, the gateway answers HTTP 429 with JSON-RPC -32005 instead of an opaque 503, because clients treat both as a signal to back off. Recent ranges do not get this answer. If every source for a recent range fails, you get a 503.
Solution
- Wait for
Retry-After(2 seconds), then retry. - Narrow the range: the message itself says ranges of 25 blocks or fewer are served more reliably.
- Backfill sequentially in small chunks, and keep a cursor so a refused chunk resumes rather than restarts.
- If a full-history scan of BSC is your main workload, this is the wrong tool: use a provider with its own archive nodes, or an indexer.
Example
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32005,
"message": "eth_getLogs capacity for deep BSC history is temporarily exhausted (blocks older than ~9000 are served by shared archive upstreams); retry in a few seconds, ranges of 25 blocks or fewer are served more reliably"
}
}FAQ
- Is this my rate limit?
- No. Your plan's limit is a plain HTTP 429 with error rate_limited and limit_rps. This one is a JSON-RPC -32005 about shared archive capacity.
- Will a higher plan fix it?
- Not directly: the limit is on shared archive sources, not on your key. Smaller ranges help more.