How SolidRPC handles RPC failures behind one endpoint

SolidRPC receives the request through its gateway, applies authentication and account policies, and routes supported traffic to capacity that can serve it. The chain, method, requested block context, freshness, and observed health all matter.

For example, a recent balance read and a historical transaction trace can require different serving paths. A node that answers the balance request may not support the trace method or retain the required historical data. Selecting a path is therefore a capability decision as well as a health decision. See the routing guide for the service boundary.

Consider a read pinned to an existing block. One eligible upstream fails to answer. Where another healthy, capable route is available and the request policy permits another attempt within its deadline, SolidRPC can try that route behind the same endpoint. The application does not need to discover or contract the replacement upstream.

A stale node presents a different problem. It can remain reachable while it loses eligibility for traffic that needs a current chain head. Routing takes freshness into account rather than treating a successful connection as proof that the node is suitable. Historical requests still need the correct method and block coverage.

A retry has a cost in elapsed time and capacity. It is a recovery mechanism, not a promise that every request succeeds or that failover adds no latency.

Recovery must preserve the meaning of the request. A request for a particular block should not silently become a request for the latest state. A batch must be examined per response, because HTTP 200 does not establish that every call in the batch succeeded.

An empty result can also be legitimate. A log range with no matching events differs from missing history or a failed request. Applications should interpret results according to the method and retain the block context needed for their own correctness checks. Our batching guide explains response IDs and partial outcomes.

Moving a request to another qualified path can restore service before the underlying node has recovered. Monitoring and repair continue behind the endpoint, and the affected path must become eligible again before it serves the relevant traffic.

This distinction matters when reading operational metrics. A request completed after retry is evidence of another successful attempt. It is not necessarily evidence that a different provider served it. The time from an alert to work starting is also different from the time needed to finish a repair. The measurement guide describes those boundaries.

When available paths cannot serve a request within its applicable limits, the application receives a failure. Preserve the timestamp, chain, method, request parameters with secrets removed, and response so support can investigate. Respect documented retry guidance and avoid retrying authentication or quota errors without resolving their cause.

A transaction-submission timeout needs particular care. The absence of an acknowledgment does not establish that the transaction was never accepted. Check the transaction hash and state before deciding how to proceed. Reconnecting a WebSocket also requires application recovery: resubscribe, retrieve missed blocks, and reconcile the cursor according to the WebSocket guide.

For supported traffic, SolidRPC takes ownership of provider selection, health-based routing, upstream failover, and the operational work behind those paths. Your team still owns application correctness, transaction intent, and workload sizing. Those responsibilities do not require maintaining a separate provider pool.

Start a migration with representative read-only fixtures, pinned historical requests, and the actual method mix your application uses. Check correctness, latency, and failure outcomes together. Then move traffic through your normal release process. The production benchmark guide provides a practical evaluation method.