Ethers.js: Allow JsonRpcProvider to retry getting its network after instantiation

[jarindr]

initializing jsonRpcProvider and calling any function before geth is healthy/run will return
could not detect network (code=NETWORK_ERROR, version=providers/5.0.0-beta.164)
this seems to work as expected

but once the geth is backed up, the error still persists.

I tried changing all the call to create a new instance of jsonRpcProvider and call the functions instead of initializing once as a singleton as example here

From

const ethers = require('ethers')
const { ETH_JSON_RPC_URL } = require('../../config')
const jsonRpcProvider = new ethers.providers.JsonRpcProvider({
  url: ETH_JSON_RPC_URL
})
module.exports = jsonRpcProvider

To

const ethers = require('ethers')
const { ETH_JSON_RPC_URL } = require('../../config')
const jsonRpcProvider = () => new ethers.providers.JsonRpcProvider({
  url: ETH_JSON_RPC_URL
})
module.exports = jsonRpcProvider

Now it works, once geth is up the server can connect to it without any problem.

also, if the jsonRpc is created after geth is healthy, but geth dies after the error is different

TypeError: Cannot read property 'body' of undefined
    at /home/jarindr/works/bitpend-backend/node_modules/@ethersproject/web/lib/index.js:138:41
    at step (/home/jarindr/works/bitpend-backend/node_modules/@ethersproject/web/lib/index.js:33:23)
    at Object.throw (/home/jarindr/works/bitpend-backend/node_modules/@ethersproject/web/lib/index.js:14:53)
    at rejected (/home/jarindr/works/bitpend-backend/node_modules/@ethersproject/web/lib/index.js:6:65)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

note: this also happen with v4 with different error like invalid response 0

[ricmoo]

During that time, can you hit the Geth externally, like using curl?

[jarindr]

@ricmoo yes, I have a service that check geth health and it is healthy once it is backup and all the jsonRPC works.

The Cannot read property 'body' of undefined problem probably come from
.on('block')event subscription
seems it is getting an error from eth node when it couldn't talk to it and didn't parse the error correctly.

[ricmoo]

Yeah, I should trap the bad body results (it is returning XML, probably) and throw a server error instead.

If you connect a JsonRpcProvider to a node that is down, and do not provide a network, it will currently never work, but that is something I could easily change.

Until the feature is added, you can resolve this by passing in a network as the second parameter. But I’ll look into this today. I have a few other things I want to get to today too and this lines up well with them. :)

[jarindr]

@ricmoo passing a networks works ! thank you. Since i'm running a geth POA just for e2e test, reading from the doc what kind of network name I should specify? kinda get that it doesn't matter but it would be good to get it documented.

Thank you for creating such a well-written eth library!

[ricmoo]

Oh, you should be able to pass in just the chain ID for PoA (as a number). Not sure what that is though, but you might know it or it is prolly easy to look up on your node.

You can pass in a string (like “homestead” or “ropsten”), a number (like 3 or 1337) or an object, if you need to configure ENS.

[jarindr]

okay ! thanks for the help.

[ricmoo]

This should work now in 5.0.0-beta.185. The Provider API was tweaked a bit to better support network discovery in the event it fails when created.

[jarindr]

@ricmoo will try it out !

[danielattilasimon]

This fix broke JsonRpcProvider for me :(

Added a comment to the offending line:
https://github.com/ethers-io/ethers.js/commit/99ae946476a317a9d89e5d8f57cf37f8680bfa2b#r39033692

[ricmoo]

Can you try 5.0.0-beta.186 that was release this afternoon and let me know if you still have any problems?

[ricmoo]

Closing this now as the above comment link indicates the latest version has fixed the issue. If not, please re-open.

Thanks! :)

[ricmoo]

(Also, the above issue is referenced in #822)