ubiquity / rpc-handler

RPC Handler NPM Package
2 stars 9 forks source link

Improving RPC health check robustness #30

Open Keyrxng opened 4 months ago

Keyrxng commented 4 months ago

The handler is now a proxy which routes on-chain read/writes through it handling retry and reselection logic. The original issue was that eth_call is not supported was being thrown by some endpoints due to network sync issues on the provider's part. While the proxy approach resolves this indirectly it could be beneficial to deal with the underlying issue.

While we can do our best to serve a healthy provider from the beginning it's possible a user call may still fail although with an improved health check this is far less likely and with our proxy the other endpoints should be also be perfectly healthy


Option 1

Current: fetch block number and ensure it's valid data Proposed: block number + permit2 read op

The health check can be improved by a number of methods but one that makes sense to me is repeating the eth_call which highlighted the issue originally


The downsides with this is:

  1. That it has been proven that the same eth_call can and will fail intermittently even with some of the best RPCs for that network, so would require best-of 3 calls for example
  2. If checks are 'fragile' like this then it's entirely possible we encounter a 'no providers found' scenario in error
  3. The more checks added the higher the chance the above happens
  4. It's still possible for a call to fail due to provider error
  5. The more calls we add the higher the network demand on load
  6. ^ the slower we are to returning a provider
  7. Our data/provider is static after load unless re-rendered/recalled

The upsides with this is:

  1. We are guaranteed healthy endpoints
  2. Less chance retry logic will be executed

Option 2

Adopt a polling-based approach, first gather our healthy endpoints and then poll them according to config settings ensuring that they remain healthy and pop them if they fault. We could collect the first pool using just the block number check and then any that make it to round two are polled with eth_call read ops.

Downsides:

Upsides:


Option two would require a pretty big overhaul of the current system as opposed to option one

Any other suggestions are welcome

related issue context https://github.com/ubiquity/pay.ubq.fi/issues/235#issuecomment-2235154700

0x4007 commented 3 months ago

2 seems more robust so that seems like the better choice.

surafeldev commented 1 month ago

/start

surafeldev commented 1 month ago

/help

ubiquity-os[bot] commented 1 month ago

Available Commands

Command Description Example
/help List all available commands. /help
/allow Allows the user to modify the given label. /allow @user1 label
/query Returns the user's wallet, access, and multiplier information. /query @ubiquibot
/start Assign yourself to the issue. /start
/stop Unassign yourself from the issue. /stop
/wallet Register your wallet address for payments. /wallet ubq.eth
surafeldev commented 1 month ago

/wallet 0x0013f4217f6a8B48A92f7EA5d811A5F8D8364B93

ubiquity-os[bot] commented 1 month ago

+ Successfully registered wallet address
surafeldev commented 1 month ago

/start

ubiquity-os[bot] commented 1 month ago
! No labels are set.
ubiquity-os[bot] commented 1 month ago

@surafeldev, this task has been idle for a while. Please provide an update.

ubiquity-os[bot] commented 1 month ago

@surafeldev, this task has been idle for a while. Please provide an update.