-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't return the internal max block number #1155
Comments
You could create a BaseProvider sub-class which stores an instance of a BaseProvider, which all calls to perform are just passed through. And on reset, create a new instance and replace it. This would be a very specific Provider to Hardhat though, since it won’t support any of the consistency attempts made by ethers, but I’m guessing this is largely for testing? I’m not too familiar with Hardhat though... |
Yes, I think we'll need to do that.
That's probably right. My personal opinion is that ethers shouldn't do this: as a user I would expect that
Yes, that's right. I think there's a chance in like a bazillion that the mainnet reorgs and goes back some blocks, but it's probably a very unlikely scenario. |
Yeah, keep in mind the ethers is not an interface to the JSON-RPC API. It happens to support talking over it, but the goal is to provide an interface to the Blockchain itself, not just what a node thinks. This is important for the highly distributed nature of blockchains and making it easier for developers, otherwise every application would need all that code that lives in ethers as boilerplate they would need to add to get a consistent view. And because of this, it is easier (i.e. possible) to piggy back on the Provider API to create things like the FallbackProvider which can operate across many backends, or even services like INFURA which also run many instances behind a single endpoint so that a slightly out-of-sync aspect does not cause applications to behave erratically. |
There's this line in
BaseProvider
:ethers.js/packages/providers/src.ts/base-provider.ts
Line 614 in e0b1d0e
that causes a problem in Hardhat (NomicFoundation/hardhat#1015)
The problem is that Hardhat Network supports resetting the network in runtime, making the block number go back to 0. But if you called
getBlockNumber
before, then the returned block number after the reset will be the max response before the reset instead of the correct value of0
.I guess changing this could be considered a breaking change, so an alternative that would work for us would be having some public method that lets us reset or ignore this
_maxInternalBlockNumber
(or anything that helps us on fixing the problem on our side). Right now the only alternative I see is making something likebefore each request, which doesn't seem like a very good idea.
The text was updated successfully, but these errors were encountered: