RPC Retry

Overview

How it works

The main risks include duplicate broadcast, retry storms, stale reads, masking permanent errors, and exceeding the user-facing latency budget. Retry behavior must account for whether the method only reads state or may create a side effect such as transaction broadcast. Configuration changes to RPC Retry should be versioned and tested under burst, timeout, dependency failure, and restart conditions.

In production, teams should define ownership and apply retryable error classification, exponential backoff with jitter, attempt caps, idempotency or transaction-hash checks, endpoint failover, and deadline budgets. The RPC Retry policy should define which failures are retryable, how long the decision remains valid, and how duplicate effects are prevented.

Useful measures include retry success rate, attempts per RPC call, duplicate broadcast count, exhausted retries, and added retry latency. RPC Retry is closely connected to Exponential Backoff, RPC Error, and RPC Failover. Metrics for RPC Retry should separate first-attempt success, recovered operations, exhausted attempts, duplicate prevention, and added latency.

For RPC Retry, a missing response should remain uncertain until status lookup or reconciliation confirms whether the original operation executed.

The RPC Retry implementation should bound attempts, preserve the original operation identity, and stop before retries amplify a dependency failure. Operational review of RPC Retry should separate successful recovery from repeated attempts that only increase latency or load.

What matters in practice

RPC retries should be driven by operation semantics and the failure category. Safe read-only calls can use bounded exponential backoff, jitter and independent provider failover. Transaction submissions require extra caution: rebroadcasting identical signed bytes is different from constructing a new transaction with another nonce. Responses such as 'already known' may mean the first broadcast worked. Rate limits and provider outages should be observed with metrics; unbounded retries can amplify an outage and delay everyone. Verify chain ID and block reference when switching RPC providers.

Related glossary concepts

Exponential Backoff; RPC Error; RPC Failover