Replies: 3 comments 11 replies
-
|
@ricmoo does this align with your views on how this should work? If yes I'd like to try implementing this. Should I target v5 or v6? |
Beta Was this translation helpful? Give feedback.
-
This is what I'd expect from FallbackProvider but seems like the name is misleading. Maybe it's better to rename the current fallback provider to QuorumProvider and have FallbackProvider attempt to try a list of providers (waterfall) when individual ones fail @ricmoo |
Beta Was this translation helpful? Give feedback.
-
|
The fallback provider doesn't work as expected (from integrator perspective), for example i wouldn't expect it to throw here if one provider is down/error-ing out. I would expect it to return the result from the working rpc endpoint const { providers } = require('ethers')
async function main() {
const url1 = 'https://optimism-mainnet.infura.io/v3/84842078b09946638c03157f83405213'
// const url2 = 'https://mainnet.optimism.io'
const url2 = 'https://example.com' // invalid url to mimic endpoint being down
const stallTimeout = 2 * 1000
const options = {
timeout: 60 * 1000,
throttleLimit: 1
}
const quorum = 1
const provider1 = new providers.StaticJsonRpcProvider({url: url1, ...options})
const provider2 = new providers.StaticJsonRpcProvider({url: url2, ...options})
const provider = new providers.FallbackProvider([
{
provider: provider1,
priority: 2,
weight: 1,
stallTimeout
},
{
provider: provider2,
priority: 1,
weight: 1,
stallTimeout
}
], quorum)
const network = await provider.getNetwork()
console.log(network)
}
main().catch(console.error)output |
Beta Was this translation helpful? Give feedback.
-
|
That’s a failure on the initialSync. That’s a much harder problem to deal with in general. Something I’ve dabbled in for v6, but basically without being able to make sure all the providers are on the same network, there is no way to even begin checking the quorum levels are valid. But it has nothing to do with the quorum or falling back. That error is happening before any of that. If you pass the Network object to the StaticJsonRpcProvider so that it doesn’t need to query its network, you shouldn’t have that problem anymore. But that problem is orthogonal to the perform operations. That problem also can’t really be solved in v5. |
Beta Was this translation helpful? Give feedback.
-
|
I think i'm not understanding why it's necessary for all providers to be online and on same network for a 1/n quorum; I would think if initial sync fails for a provider then treat that provider as returning a failed response and as long as 1 provider returns a valid response then that should be the returned result |
Beta Was this translation helpful? Give feedback.
-
|
For a set of providers that are not all on the same network, which network should it be considered to be on? If you create a FallbackProvider with one provider on Görli and one provider on Mainnet, what should happen. It is dangerous to make any assumptions in this case, even with a 1/n quorum. Alternating between them will cause absolute chaos. So, the constructor for FallbackProvider ensures all providers are on the same network. And a JsonRpcProvider that doesn't have an explicit Network (i.e. by setting it in the constructor), uses the eth_chainId to look this up. If the provider is down, it cannot do this. So, to ensure offline providers work, they need an explicit Network passed into the constructor, which helps the FallbackProvider know that if that provider comes back online, it won't start providing bad data (since a provider verifies its network and will fail itself if the network has changed). Does that make sense? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for clarifying that, I see why it's necessary now! I'll try passing the network in the constructor in that case |
Beta Was this translation helpful? Give feedback.
-
|
A 429 will still retry (after the proper amount of time, explicit retry-after is honoured, otherwise an implicit exponential-backoff is used). After the stall-timeout, the next provider is kicked off regardless, the stall-timeout can be adjusted, but most retry-after timeouts are longer than the default 600ms, so the next in the list will begin and run in parallel to the first; whichever responds first will get the first stab at resolving the quorum. I think the OP has made wrong assumptions about the fallback provider. A quorum of 1 will still try the next provider in the list, on a non-response error, such as a server error. But if I for example, ask for the result if a call (which is what estimate gas is, effectively) and the result is a call exception, that is the result. If you ask some service for the result of “what is 5 diced by 0”, and the response is “error; division by zero”, that is the result and there is no reason to ask the next service. If you have added additional server-side constraints to a node, and use that in a FallbackProvider, that response is out of band, and it cannot know that that server is (albeit, intentionally) incorrectly responding to a request. You will need to configure each backend to have the same rules. The FallbackProvider, falls back onto other services only when the error is recoverable and the backend queried just failed. If the backend returns a result that is systemic, there is no reason to try the next. Does that make sense? |
Beta Was this translation helpful? Give feedback.
-
The story here is more "what is 5 divided by 0" and the server responds "Error: missing revert data in call exception; error={body: {error: 'i don't support divisions'}}" @ricmoo then perhaps the request is better error handling 🤔, but i see your point of rpcs behaving very different to each other. Looking at: In the case of allowList errors: |
Beta Was this translation helpful? Give feedback.
-
|
If the response is a “revert error”, it should return the revert error, since that is the correct response; we tried a call and it returned a result (a result with status = 0, but that’s still a response). There is no reason to assume the next provider won’t also return a |
Beta Was this translation helpful? Give feedback.
-
|
I don't necessarily disagree with that (especially in the case of code=0) and it's pain that every rpc behaves differently. That said wouldn't it be reasonable to handle some codes differently though? |
Beta Was this translation helpful? Give feedback.
-
|
Oh, do you have any links to those error codes? Along with any others? |
Beta Was this translation helpful? Give feedback.
-
|
I know call exception is the result, but could we have a Provider level error handling callback?
|
Beta Was this translation helpful? Give feedback.
-
Describe the Feature
As I understand the code of the current FallbackProvider with
nproviders and a quorum of1it would always do a single request and if that fails fail. For rpc errors like gas estimation, that is somewhat reasonable but for some other errors it is not.The specific case i'm currently looking at is a
FallbackProvider([privateRPCWithContractAllowList, publicRPC])my thinking was - when for some reason i forgot to allowList a contract address the request would fail, but then be resolved on the public one.That is not the case though and i think with the current
FallbackProviderthat behaviour is also not enforceable.With a quorum of
1you would always do one request, failing when the first one fails.With a quorum of
2you would always do two requests, which would still fail with quorum not reached in case the first one fails.Therefore I think certain errors (also e.g. network errors like 429) should result in a retry on another provider when using a Fallbackprovider.
TBH i was under the impression that this is how the FallbackProvider already works("falling back"), but after looking at the source I think it isn't 😅
Code Example
No response
I think this intersects a bit with #2937
Beta Was this translation helpful? Give feedback.
All reactions