CPU spinning + browser unresponsiveness on network switch

[kerzhner]

In our dapp that uses ethers 5.0.0-beta.187 + Metamask + Chrome or Firefox, we are observing the following:

1. Load the dapp with Metamask pointed to local ganache.
2. Switch Metamask to Ropsten.
3. Observe CPU of the tab go to 100%.
4. Pause script execution in Chrome. The execution pauses on the following in base-provider.js:

for (let i = this._emitted.block + 1; i <= blockNumber; i++) {
  this.emit("block", i);
} // The emitted block was updated, check for obsolete events

One example of values int he loop are this._emitted.block of 54 and blockNumber of 8,012,600. With these values, the loop will iterate 8 million times.

[ricmoo]

It’s a good question as to what should happen. The network for a Provider is never meant to change. When the network changes, a new Provider should be instantiated... but if it isn’t, these cases are hard to efficiently detect.

I’ll think of something today and try a few things out.

[ricmoo]

Related to #495

I've added some basic support for Providers that support the network changing. To enable it, the network must be specified as "any".

Once that is done, the "network" event will be triggered on any network change and any block events will be reset for the current block on that network (the events are not removed). Also, any delta of over 1000 blocks will emit a block skew error and fast-forward to the current block (this will not happen in the case of a network change, which just resets the block number; this happens more if you close your laptop and come back a few days latter).

If a Provider is not marked as "any" network, and the network changes, all operations on that Provider will throw an error and the events will be suspended until the underlying network is restored.

I'm adding a section in the docs on this now. Keep in mind there are potentially a lot of edge cases to handle if you are supporting network changes.

Also, to simplify life, and get back to the old Metamask behaviour of refreshing the page on network change (most regular users won't be switching networks; so this won't impact them):

// Force page refreshes on network changes
{
    // The "any" network will allow spontaneous network changes
    const provider = new ethers.providers.Web3Provider(window.ethereum, "any");
    provider.on("network", (newNetwork, oldNetwork) => {
        // When a Provider makes its initial connection, it emits a "network"
        // event with a null oldNetwork along with the newNetwork. So, if the
        // oldNetwork exists, it represents a changing network
        if (oldNetwork) {
            window.location.reload();
        }
    });
}

At a minimum, most applications that support network changes will want to provider.removeAllListeners() on network changes, and re-establish their events.

The CI is running right now, and once all the tests pass, I'll publish to npm. :)

[ricmoo]

The CI is done, try out 5.0.0-beta.191 and let me know if it works for you. :)

[kerzhner]

Really appreciate how quickly you came up with a fix @ricmoo. The right path for us will be to reload the page on network change. So your code sample is very helpful.

Unfortunately, when trying to test out the latest version, we are running into #865.

[ricmoo]

I posted in the other issue. Basically, the lock files need to be reset. Let me know if you still have any problems.

Sorry for the inconvenience.

[kerzhner]

Tried out listening to the network event and triggering a page reload using ethers 5.0.0-beta.191. Works like a charm. Thanks @ricmoo!

[ricmoo]

Glad to hear it! :)

Closing now, but reach out if there are any further issues.

Thanks! :)