Add chain_id setter to avoid eth_chainId requests

[medariox]

What was wrong?

Every time the chain_id property is called, an eth_chainId request is triggered.

How was it fixed?

By manually specifying the chain_id, the request can be avoided.

web3 = Web3(HTTPProvider(...))
web3.eth.chain_id = 1 # mainnet

As a further improvement, it may be beneficial to cache the result of the first eth_chainId request.
The current change is intentionally conservative: there is no behavioral change if the setter is not used.

Todo:

• Add entry to the release notes

Cute Animal Picture

[antazoey]

Would it make sense to set _default_chain_id here before returning the value?

[medariox]

Yes, it totally would! (That's what I meant with: "As a further improvement, it may be beneficial to cache the result of the first eth_chainId request.")

But that would also change the current behavior and I don't know if that's something that is wanted.

[kclowes]

Thanks @medariox! I assume this fixes the chain_id issue where it's requesting the chainId even though it shouldn't? Do you mind adding a test for that?

[medariox]

Thanks @medariox! I assume this fixes the chain_id issue where it's requesting the chainId even though it shouldn't? Do you mind adding a test for that?

Sorry for the late reply.
This will avoid requesting the chainId every time the web3.eth.chain_id property is called (if previously set with the setter).
The question is: do we also want to avoid requesting the chainId after we have a chainId from the request as @unparalleled-js suggested (without having to set it manually, basically caching it after the web3.eth.chain_id property si called the first time)?

I'll try to add some meaningful tests next week.

[kclowes]

do we also want to avoid requesting the chainId after we have a chainId from the request as @unparalleled-js suggested (without having to set it manually, basically caching it after the web3.eth.chain_id property si called the first time)?

If I understand this code correctly, I think I lean towards no, because as it stands right now, when we call w3.eth.chain_id, we are asking the chain "what is your chain_id" vs. asking "what is the chain_id I've set", if that makes sense. And I think we want to maintain the functionality that asks "what is the chain_id for the chain I'm connected to" without having to manually set the default_chain_id to None every time we need an answer to that question. But if either you or @unparalleled-js have a strong opinion otherwise, I'd love to hear it.

And btw if you're seeing Timeout failures on integration tests, feel free to ignore. Those are just flaky.

[medariox]

do we also want to avoid requesting the chainId after we have a chainId from the request as @unparalleled-js suggested (without having to set it manually, basically caching it after the web3.eth.chain_id property si called the first time)?

If I understand this code correctly, I think I lean towards no, because as it stands right now, when we call w3.eth.chain_id, we are asking the chain "what is your chain_id" vs. asking "what is the chain_id I've set", if that makes sense. And I think we want to maintain the functionality that asks "what is the chain_id for the chain I'm connected to" without having to manually set the default_chain_id to None every time we need an answer to that question. But if either you or @unparalleled-js have a strong opinion otherwise, I'd love to hear it.

And btw if you're seeing Timeout failures on integration tests, feel free to ignore. Those are just flaky.

I tend to agree with you. I was thinking about the possibility because as long as the endpoint (chain provider) is not changed, there should be no way to get a different result. That's my current understanding of it, but I may be wrong and I don't want to risk breaking anything. 😅

[BoboTiG]

The patch seems quite interesting, what is the status? :)

[medariox]

@BoboTiG
I'm not sure what is holding it back. The PR is ready from my side.

[kclowes]

Thanks @medariox! This looks great! Sorry it took me so long to circle back. I moved the newsfragment to be a feature instead of misc and pulled in the most recent master. I'll also cherry-pick this onto our v5 branch.

[kclowes]

We were talking about this internally - does anyone have a use case where you wouldn't use the chain_id returned by w3.eth.chain_id? We were thinking of either:

1. making a w3.eth.chain_id call on provider instantiation and setting the default_chain_id that way, or
2. validating that the default_chain_id that gets set is the same as the one that gets returned by w3.eth.chain_id

Does anyone have any opinions?