Open Keyrxng opened 4 months ago
2 seems more robust so that seems like the better choice.
/start
/help
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 |
/wallet 0x0013f4217f6a8B48A92f7EA5d811A5F8D8364B93
+ Successfully registered wallet address
/start
! No labels are set.
@surafeldev, this task has been idle for a while. Please provide an update.
@surafeldev, this task has been idle for a while. Please provide an update.
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 originallyThe downsides with this is:
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 exampleThe upsides with this is:
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