RPC Timeout

Overview

An RPC Timeout occurs when a blockchain RPC request does not complete within the configured connection, response, or total deadline. It can reflect network delay, provider overload, expensive node execution, or a client-side deadline that is too short. Provider failover for RPC Timeout should not create a second transaction or replace a verified chain result with stale node data.

The main risks include duplicate submissions, abandoned pending operations, cascading retries, long resource retention, and false provider failover. A timeout creates uncertainty for state-changing methods because the node may have accepted a transaction even though the client did not receive the hash.

In production, teams should define ownership and apply method-specific deadlines, cancellation, trace IDs, safe retry rules, transaction-hash recovery, alternate endpoint queries, and timeout budgets. The RPC Timeout implementation should distinguish node acceptance, transaction broadcast, execution, confirmation, and indexed visibility where those stages apply.

Useful measures include RPC timeout rate by method, timeout stage, recovered transaction count, p95 duration, and timeout-triggered failovers. RPC Timeout is closely connected to Request Timeout, RPC Retry, and Transaction Query. When nodes disagree during RPC Timeout, the application should preserve both observations and defer irreversible action until the authoritative chain state is clear.

For RPC Timeout, the client should retain chain, method, block or transaction reference, provider response, and the final on-chain observation.

Testing RPC Timeout should include provider disagreement, reorganization or indexing delay, malformed data, and an unavailable node when relevant to the method. An RPC Timeout client should validate network identity, units, encoding, and method semantics before acting on provider data.