Constantly getting "Could not detect network errors"

[rhlsthrm]

We have a system running in production which is generating frequent error logs with this message:

"Error","message":"could not detect network (event=\"noNetwork\", code=NETWORK_ERROR, version=providers/5.0.23)","stack":"Error: could not detect network (event=\"noNetwork\", code=NETWORK_ERROR, version=providers/5.0.23)\n    at Logger.makeError (webpack:////root/node_modules/@ethersproject/providers/node_modules/@ethersproject/logger/lib/index.js?:179:21)\n    at Logger.throwError (webpack:////root/node_modules/@ethersproject/providers/node_modules/@ethersproject/logger/lib/index.js?:188:20)\n    at JsonRpcProvider.eval (webpack:////root/node_modules/@ethersproject/providers/lib/json-rpc-provider.js?:407:54)\n    at step (webpack:////root/node_modules/@ethersproject/providers/lib/json-rpc-provider.js?:46:23)\n    at Object.eval [as throw] (webpack:////root/node_modules/@ethersproject/providers/lib/json-rpc-provider.js?:27:53)\n    at rejected (webpack:////root/node_modules/@ethersproject/providers/lib/json-rpc-provider.js?:19:65)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (internal/process/task_queues.js:97:5)","reason":"could not detect network","code":"NETWORK_ERROR","event":"noNetwork"},"msg":"could not detect network (event=\"noNetwork\", code=NETWORK_ERROR, version=providers/5.0.23)"}

Any idea what could be causing it? I'm looking at my providers and I don't seem to be hitting rate limits. How can I catch this error or find out where in my code it's coming from?

[yuetloo]

Check your url, make sure the path is correct, the api key is correct.

[conorbros]

What environment are you in?

[rhlsthrm]

Check your url, make sure the path is correct, the api key is correct.

Everything is correct, it does not happen all the time.

What environment are you in?

This is running in Node.

[rhlsthrm]

Would this happen if there was a provider rate limit?

[reuptaken]

I had this too. It's a problem with some internet providers (not node providers!) Check your code on some remote server.

I've switched to WebSocketProvider and this problem is gone now.

[rhlsthrm]

I had this too. It's a problem with some internet providers (not node providers!) Check your code on some remote server.

I've switched to WebSocketProvider and this problem is gone now.

It's running on an AWS instance. Did you have a similar issue? I don't think I can use websocket provider because I am using other chains and L2s which don't all have websocket providers.

[reuptaken]

I had similar issue on my home machine but it was ok when I run the same code on Google Cloud (and then I switched to websockets). It was presumably some issue with depleting some kind of network resources (like max network connections or something alike).

But of course the nature of your issue may be completely different.

[rhlsthrm]

Is there any way to know what function it's coming from? I'd like to be able to catch the error at least.

[conorbros]

Are you using one provider to connect or making new instances frequently?

[rhlsthrm]

Are you using one provider to connect or making new instances frequently?

I thought you were onto something but I just checked the code, and we are reusing the providers. Any other reason why this would be happening? What method is this coming from?

[rhlsthrm]

We are doing something like this every 30 seconds:

    await Promise.all(
      Object.entries(hydrated).map(async ([chainId, provider]) => {
        // base asset
        const balance = await provider.getBalance(signerAddress);
        const chainInfo: ChainInfo = await getChainInfo(Number(chainId));
        const baseAssetName: string = getAssetName(Number(chainId), AddressZero);
        this.set(
          { chainName: chainInfo?.name ?? chainId, chainId, assetName: baseAssetName, assetId: AddressZero },
          parseFloat(formatEther(balance)),
        );

        // tokens
        await Promise.all(
          Object.entries(rebalancedTokens[chainId] ?? {}).map(async ([assetId, config]) => {
            const balance = await config.contract.balanceOf(signerAddress);
            const assetName: string = getAssetName(Number(chainId), assetId);
            const toSet = await parseBalanceToNumber(balance, chainId, assetId);
            this.set({ chainName: chainInfo?.name ?? chainId, chainId, assetName, assetId }, toSet);
          }),
        );
      }),
    );

Where hydrated is a list of providers for different chains. Is there anything wrong with this strategy? The providers are not being recreated, they are created once when the app loads.

[conorbros]

I'm not sure what function is causing it. My assumption is it would be one of provider.getBalance or config.contract.balanceOf(signerAddress) as those are the two that I am sure are using a provider.

Just something that may narrow the problem: Does the same code run asynchronously work? Could be something to do with many synchronous calls to the provider.

[rhlsthrm]

@conorbros how do you mean run asynchronously? We are running this asynchronously, parallelized over the providers. Can you provide another example of running it asynchronously?

[conorbros]

Aren't you then parallelizing over all the tokens on each provider?

[rhlsthrm]

Aren't you then parallelizing over all the tokens on each provider?

Yes, you're correct, the tokens are being parallelized. We will try to make this synchronous.

[conorbros]

Okay, hopefully that should narrow the problem. You might also find its a specific provider causing the error.

[ricmoo]

This is often a link problem with the backend node. As other have pointed out this could be a URL problem (since a bad URL cannot be connected to ;)), but can also occur in testing when an attempt is made to connect to a node that is not up and running yet.

If there are proxies in the way, problems can also occur if they are not properly forwarding proper error codes or in the case of CORS the OPTIONS request for pre-flighting the request.

Basically, this is a hard to debug issue, because it is usually not at the application level.

My first suggestion to start debugging, when possible (e.g. on a host), is to use curl or wget to make sure normal requests work. If in a browser, check the network tab in the inspector for the calls to eth_chainId (for JSON-RPC providers) to see that any needed CORS requests are correctly getting pre-flighted; if they aren't, the result is likely a 403 for no apparent reason. Additionally, a 403 response can happen on some backends if rate limiting is occurring (the backend should use 429, but not all backends are well-behaved).

I hope that helps. And if you find the problem and solution, post it here too, so others can benefit from your anguish. :)

[rhlsthrm]

Thanks, @ricmoo! My main question is what function it's coming from. Is there some way I can try-catch for it?

[ricmoo]

(moving to discussions)

[makoto]

Hi. I am getting the same error but against the local private chain (ganache). I can see that the ganache log has received eth_chainId in their log.

[ricmoo]

Could it be a CORS issue? Is the Ganache instance correctly configured to allow access from your site?

[maxholloway]

I'm seeing this issue when running a ganache rpc locally. When creating a provider, I was specifying the following.

new ethers.providers.JsonRpcProvider("http://localhost:8545")

When I changed the url from localhost to 127.0.0.1, it no longer saw this issue.

new ethers.providers.JsonRpcProvider("http://127.0.0.1:8545")

[spyboy7711]

Thanks, it worked for me