Describe the bug
To Reproduce
Steps to reproduce the behavior:
https://api.myetherwallet.com/ethhttps://api.myetherwallet.com/ropAssertionError: Provided chainId (1) must match the active chainId (4)
Expected behavior
Custom RPC must not use hardcoded values
Browser details (please complete the following information):
Additional context
I have created PR to remove hardcoded chainId
https://github.com/danfinlay/js-eth-personal-sign-examples/pull/7

I also wasn't able to send any transactions from custom RPC URLs, and when I click on Tx Hash, it redirects me to rinkeby.etherscan.io
I believe it's ignoring custom rpcs and reading from last network id from dropdown which is rinkeby
I'm not familiar with metamask code base, but I suspect
https://github.com/MetaMask/metamask-extension/blob/develop/app/scripts/controllers/network/network.js#L118
Basically when you do
ethQuery.sendAsync({ method: 'net_version' }, (err, network) => {
log.info('web3.getNetwork returned ' + network)
this.setNetworkState(network, type)
}
})
you are not getting network, instead, you are receiving object.
Also, in some RPC urls, you have to provide jsonrpc: "2.0" when using sendAsync
Example: https://api.myetherwallet.com/eth
I haven't ran the code, but I think there might be an issue
ethQuery.sendAsync({ method: 'net_version' }, (err, result) => {
const network = result.result
log.info('web3.getNetwork returned ' + network)
this.setNetworkState(network, type)
}
})
@danfinlay
I personally learned on that PR, playing around with different type of params.
Good catch, thanks! I鈥檓 surprised this bug sat in prod for so long! I guess it shows signTypedData is finally getting some exploration? I鈥檓 definitely excited to see it combined with solidity 0.5.0 structured params.
I think your diagnosis looks right, but I鈥檒l take a closer look and verify.
https://github.com/MetaMask/metamask-extension/issues/5934 makes it sound like it's an issue with applying custom RPC networks, not limited to signTypedData
missing repro step:
bug notes:
seems to be a bad cached value in the provider for type: rpc
solution ensure the look up of chainId before _configureProvider
more notes:
Seems part of this issue is that what ever the "provider" inpage is returning for chain Id does not seem to update properly on network switches the simple hack of setting the chainId during networkController.lookupNetwork does not solve this issue and chainId is also persisted in preferences controller for some reason. and could possibly be causing some of these problems
@frankiebee that's what I tried to say at the end of the bug report that even sending ANY tx on custom RPCs doesn't work
@frankiebee @rstormsf I followed the repro steps (see gif below), but did not see the error. Is there an inconsistency between the steps I followed and what you are doing to hit this error?

@danjm Make sure you have more than 1 Custom RPC in your list

@danjm
@danjm I鈥檓 able to reproduce it as well
just to clarify with 2 custom rpcs, you cannot send a transaction from that rpc
@frankiebee it's ok, I can re-add them. Please let me know when I can test the fix on which metamask version release.
I believe it should be able to have more than 1 custom rpc without hard-coded rinkeby(4) chainId.
In order to know whether the chainId is correct or not - I don't believe it's responsibility of metamask, it should only query net_version API and that should be it.
Most helpful comment
more notes:
Seems part of this issue is that what ever the "provider" inpage is returning for chain Id does not seem to update properly on network switches the simple hack of setting the chainId during
networkController.lookupNetworkdoes not solve this issue and chainId is also persisted in preferences controller for some reason. and could possibly be causing some of these problems