Immutable Providers means network changes go undetected
See original GitHub issueI’m using ethers.js 4.0.33 and MetaMask, and I query the provider for block events with:
provider.on("block", (blockNumber) => { ... })
When I change the network ethers.js stucks and the application with it, and it seems true in particular when the difference between blocks in the network is very large. For example, first go with Goerli, 1M blocks, and then switch to Kovan, 12M blocks: the library tries to fire 11M of remaining events.
I think the problem is here: https://github.com/ethers-io/ethers.js/blob/master/src.ts/providers/base-provider.ts#L587-L589 and I think this should be fixed resetting all events when network changes.
To be more conservative, I tried to use the resetEventsBlock(blockNumber: number)
function, but it seems it contains an error because it does not reset _emitted.block
. I sent a PR to solve this, so you can do something like this: https://github.com/Neurone/mom/blob/development/src/index.js#L91-L93
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:10 (5 by maintainers)
Top GitHub Comments
So, after working more on this and related things, I don’t think this will be addressed in the Provider until ETH2.0 when there is a need for the Provider to be network-change aware.
I have made my case to MetaMask why it should refresh the page on network change, but I will provide a cookbook recipe to do this yourself too. A supplementary library I’m working on will also help with this, the ProviderManager which will be added to the
experimental
package.The main reason I think pages should refresh is that this is only an issue developers have to deal with, normal users shouldn’t ever be changing to testnets (and it can lead to uninformed users into being scammed). Dealing with changing networks is actually very difficult, with a lot of edge cases a developer must handle, and if even small mistakes are made, unhappy things will happen, and it becomes very difficult to debug/verify (and results in the developers’ classic “well it works fine on my computer” and therefore “you must be using it wrong”).
In my opinion, the ability to change networks should not even be active by default, in the same way the
developer menu
is hidden in a browser and requires a user to specifically undergo an action to enable it. Developer mode can very quickly damage a non-developers ability to understand their browser.Obviously these are just my opinions, and for those who wish to work around it, a ProviderManager will make it less difficult.
Hmmm… This is an interesting issue. We basically need a provider to become mute once the network changes. Providers are immutable (including the network), and this can cause strange issues if we allow the same provider to be queried when the backend changes.
I’ll think about this case too, as I already have a few related things to ponder.
Basically, I recommend in general using the default provider, connected to your network of choice, and use MetaMask as a Signer, and when the signer’s network changes, respawn the Provider and set everything up. I’m working on a library to facilitate this into a more meaningful API.
Really, I think MetaMask and ilk should not permit non-homestead networks (or changing networks) unless they are switched into developer mode, as it can be dangerous for “normal” users to have access to (and have to think about) development networks. If only developers have testnets, many of these issues go away… Anyways, that is a topic for another day. I will think more about this, thanks. 😃