Infinite loop in _start() at provider-jsonrpc.ts

[ErrorEater]

Ethers Version

6.2.3

Search Terms

Infinite loop, _start()

Describe the Problem

What I want to do is to create a rpc provider from an address and if there is any error reading from that address to be able to switch to another one. Unfortunately, on provider creation the provider loops infinitely by trying to connect to the address.
That behavior should be left to the user.
If you don't want to change the current behavior a boolean parameter at a constructor to override the default behavior can be helpful.

const reader = new JsonRpcProvider("http://127.0.0.1:8545/");

try {
	await reader.getBlockNumber();
	setReader(reader);
} catch (error) {
	setReader(undefined);
}

Here is where the infinite loop happens, provider-jsonrpc.ts line 600 while trying to detect the network:

_start(): void {
	if (this.#notReady == null || this.#notReady.resolve == null) { return; }

	this.#notReady.resolve();
	this.#notReady = null;

	(async () => {

		// Bootstrap the network
		while (this.#network == null) {
			try {
				this.#network = await this._detectNetwork();
			} catch (error) {
				console.log("JsonRpcProvider failed to startup; retry in 1s");
				await stall(1000);
			}
		}

		// Start dispatching requests
		this.#scheduleDrain();
	})();
}

Code Snippet

No response

Contract ABI

No response

Errors

No response

Environment

Browser (Chrome, Safari, etc), Other (please specify)

Environment (Other)

SolidJS

[ricmoo]

You are right that at the very least the .destroy() method should terminate this loop.

The problem is that often times people start a JsonRpcProvider before the server (e.g. dev Geth) is up and running, so we want to make sure it gets a fair chance to start, otherwise the provider is just in a dead state.

I'll investigate this and see what other ideas I can come up with...

[ricmoo]

This has been address in v6.5.0.

You can now use something like provider.on("error", (e) => { if (isError(e, "NETWORK_ERROR")) { provider.destroy(); } }) and the provider will be shut down and the loop terminated.

The provider.on("error", ...) will also be used at some point to help let a provider notify a FallbackProvider that it is no longer fit for service.

Let me know if you have any other suggestions.