Replies: 4 comments 1 reply
-
I agree with you, but unfortunately this is how the nodes work and their provided API. I’ve spoken up at the JSON-RPC API meetings about this, but there is currently no way to distinguish if the results took a provided blockTag into account or not. If you need blockTag-based responses, you will have to make sure all your backends are full archive mode (or partial archive mode and ensure your block ranges are within their safe range). |
Beta Was this translation helpful? Give feedback.
-
This is an issue with ethersjs not with RPC, the problem is that:
So:
works properly but when I add the fallback provider wrapping it breaks |
Beta Was this translation helpful? Give feedback.
-
I'm encountering this too - I want a FallbackProvider consisting of archive nodes, but the provider silently strips the At a glance, this looks suspicious - I would have expected |
Beta Was this translation helpful? Give feedback.
-
Thanks! I realize now what you meant, and this has been fixed in ab43e7d and will be released in v5.7. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
FallbackProvider doesn't work handle blocktags correctly
Reproduce
ignores the blocktag and instead returns the result as if blockTag was "latest". This should clearly break otherwise, we are trying to query a contract that didn't exist at block 1
Beta Was this translation helpful? Give feedback.
All reactions