Closed Keyrxng closed 3 months ago
I wasn't able to really understand why they were failing in the first place but in manual testing this approach resolved the issue every time.
I will add some tests to cover it, I'm unsure how well Cypress
will be able to test it so it may have to be with Jest
I was thinking maybe to just use the ethers.providers.FallbackProvider
and have each latency entry as a node but that has it's own array of potential errors to handle
@rndquu should this be closed or used as a stop gap until rpc-handler
has been updated?
@rndquu should this be closed or used as a stop gap until
rpc-handler
has been updated?
I think it makes sense to close this PR, wait for https://github.com/ubiquity/rpc-handler/issues/23 and then update the code in this repo accordingly
Resolves #235
Wrapped
app.provider
in aProxy
to catch any failed call across the appQA:
You see two page loads that require the proxy to select a new provider and retry, the third requires no retry.
You see two sets of logged failures because the app makes a call on page load, this cannot be effectively removed as a successful RPC will not need changed as seen on the 3rd page load. The proxy uses the first stored RPC and then loops the latencies retrying until successful.
https://github.com/ubiquity/pay.ubq.fi/assets/106303466/473f9885-9d8d-4bd0-8c9a-8efd5796e1db