Improving RPC health check robustness

[Keyrxng]

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:

8. We are guaranteed healthy endpoints
9. 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:

• Perpetual read ops called
• runtime network demand depending on settings and amount of providers to poll
• We may hit call limits with our check and serve it for the user to get rate limited (low chance)

Upsides:

• Dynamic health status
• Potentially makes retry logic obsolete
• network load demand is on par with option 1

---

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 ubiquity/pay.ubq.fi#235 (comment)

[0x4007]

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

[surafeldev]

/start

[surafeldev]

/help

[ubiquity-os]

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]

/wallet 0x0013f4217f6a8B48A92f7EA5d811A5F8D8364B93

[ubiquity-os]

+ Successfully registered wallet address

[surafeldev]

/start

[ubiquity-os]

! No labels are set.

[ubiquity-os]

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

[ubiquity-os]

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