Problem

The RPC service currently triggers the circuit breaker for HTTP 405 (Method Not Allowed) and 429 (Too Many Requests) status codes, which might not be the correct behavior. These responses indicate different conditions that should be handled differently:

405 (Method Not Allowed)

• Indicates the RPC method is not supported by the endpoint
• Is a permanent condition, not a temporary failure
• Opening the circuit breaker won't help since retrying will always get the same response
• The endpoint is actually working correctly, just doesn't support that method

429 (Too Many Requests)

• Indicates a temporary rate limiting response
• The endpoint is working correctly but asking us to back off
• Opening the circuit breaker is too aggressive - we should just respect the rate limit
• Should implement proper rate limit handling with exponential backoff or respect the Retry-After header

Current Implementation

if (response.status === 405) {
  throw rpcErrors.methodNotFound();
}

if (response.status === 429) {
  throw rpcErrors.internal({ message: 'Request is being rate limited.' });
}

Proposed Solution

1. For 405:

   • Return a proper RPC error response instead of throwing
   • Use standard JSON-RPC error code -32601
   • Allow application to handle unsupported methods gracefully

2. For 429:

   • Return a proper RPC error response instead of throwing
   • Use a custom error code for rate limiting
   • Implement Retry-After header support
   • Include retry delay information in the response

Related Files

• packages/network-controller/src/rpc-service/rpc-service.ts