Error classification

Lasso RPC Core v0.5.0 classifies upstream responses and transport failures to decide whether another provider may be tried and whether a transport’s circuit breaker should be penalized. Classification is internal routing behavior. A valid, request-correlated upstream JSON-RPC error retains its original code, message, and optional data in the caller response.

​

Decision order

The released classifier checks structural revert evidence and definitive codes before message patterns. For ambiguous codes, it uses bounded message evidence for execution errors, provider limits, authentication, and capabilities, then falls back to the code. For example, a provider may use -32603 for a capability restriction; that code alone is not a definitive internal-error verdict. An EVM revert is a request-caused outcome, even when provider wording also mentions a limit.

​

Failover and breaker behavior

The table describes the classifier’s category functions. Request execution also applies method safety, transport policy, remaining deadline, candidate admission, and dispatch limits. A category marked “Yes” does not authorize replaying a signed transaction or exceeding its one-dispatch budget. See the method contract and routing strategies.

​

Provider-specific rules

Profile capabilities.error_rules can classify a provider’s observed code or message. Use the narrowest supported match and qualify it with your upstream: provider wording and plans change. Rules affect routing and health decisions, so a broad false match can either cause unnecessary failover or hide a real provider failure. See provider capabilities.

​

Inspecting a failure

Request metadata to see recorded channels and categories where available. A candidate list is not a dispatch log, and missing attempt metadata is unknown rather than proof that no dispatch occurred. Keep the request ID, method, profile, chain, original error, and source version when investigating a discrepancy. Do not log provider credentials or full URLs.