[Bug]: Cannot get the latest value after switching the network

[coding-ice]

Describe the bug

Cannot get the latest value after switching the network
link: https://stackblitz.com/edit/vitejs-vite-9rayvh?file=src%2FApp.tsx

Expected behavior

correct version: 11.14.5 - x

No response

Screenshots/Recordings

No response

Steps to reproduce

1. Click button change to BNB chain.
2. Switch metamask to other chain.
3. Can't get the latest value.

Error messages or log output

No response

Version

11.16.7

Build type

None

Browser

Chrome

Operating system

MacOS

Hardware wallet

No response

Additional context

No response

Severity

No response

[disappearer]

I can confirm this. Our app heavily relies on network switching and this issue is making it unusable with MetaMask. This was working a few days ago.

[coding-ice]

Please check as soon as possible, thanks.

[adonesky1]

Hey @coding-ice thanks for your report here. We have a fix for this issue that is rolling out with version 11.16.7

Edit: Actually you are reporting that you are seeing this on 11.16.7... We'll take a look!

[adonesky1]

Can you explain what you mean by "Cannot get the latest value"? Do you mean if you call eth_chain you are not receive any response? Or you're not seeing the correct response?

[tmm]

Reproducible via running RPC requests in the browser console. More info in this comment wevm/wagmi#3998 (comment)

// start with extension on mainnet, then request accounts:
> await window.ethereum.request({ method: 'eth_requestAccounts' })
[...]
> await window.ethereum.request({ method: 'eth_chainId' })
'0x1'
> await window.ethereum.request({ method: 'wallet_switchEthereumChain', params: [{ chainId: '0x89' }] })
> await window.ethereum.request({ method: 'eth_chainId' })
'0x89'
// switch in extension ui, then run the following:
> await window.ethereum.request({ method: 'eth_chainId' })
'0x89' // should be 0x1

[Gudahtt]

We have been able to reproduce this bug, and are currently investigating. We will post an update soon.

[Gudahtt]

We have found the problem, and are preparing a fix. We'll have this released as soon as we can.

[coding-ice]

ok,thanks a lot~

[c0da523]

Reproducible via running RPC requests in the browser console. More info in this comment wevm/wagmi#3998 (comment)

// start with extension on mainnet, then request accounts:
> await window.ethereum.request({ method: 'eth_requestAccounts' })
[...]
> await window.ethereum.request({ method: 'eth_chainId' })
'0x1'
> await window.ethereum.request({ method: 'wallet_switchEthereumChain', params: [{ chainId: '0x89' }] })
> await window.ethereum.request({ method: 'eth_chainId' })
'0x89'
// switch in extension ui, then run the following:
> await window.ethereum.request({ method: 'eth_chainId' })
'0x89' // should be 0x1

I met this problem too.I thought there are somewhere cached in my browser.

a hack to resolve this problem

window.ethereum.on('chainChanged', async (chainId) => {
  console.log('Network changed to:', chainId);

  window.ethereum.request({
    method: 'wallet_switchEthereumChain',
    params: [{ chainId }],
  });
  const currentChainId = await window.ethereum.request({
    method: 'eth_chainId',
    params: [],
  });
  console.log('Current chainId from ethereum request:', currentChainId);

  // window.location.reload();
});

[Sotatek-ToanHa]

please we are also having the same problem

[adonesky1]

Thank you for your patience. A fix will be released with 11.16.8. Should be going live today!

[danjm]

The fix for this has been published as part of the 11.16.8 release

You may need to manually update your metamask install to access this fix. https://support.metamask.io/managing-my-wallet/using-metamask/how-to-update-the-version-of-metamask/#:~:text=Chrome%2Dbased%20browsers%3A%20Click%20the,manually%20install%20it%20from%20here.

[jxom]

For the future, bugs like these should be tagged as sev-critical.

Most libraries perform chainId checks to assert the user is on the right chain before executing a transaction.

[Sotatek-ToanHa]

Thank you for your patience. A fix will be released with 11.16.8. Should be going live today!

I have found it to work properly. Thank

[matthewlilley]

For the future, bugs like these should be tagged as sev-critical.

Most libraries perform chainId checks to assert the user is on the right chain before executing a transaction.

Absolutely is a critical bug that caused real users to lose funds. We had a case of a user losing ETH because of this. A synchronicity bug like this is one we fear most, because of the behaviour when a method call is made to a non-contract address with ETH, it will succeed in sending the ETH and will be lost permanently. Damage here could've been substantial.

Any ideas on what we could do to safe guard against bugs like these in future?

[simonazhang68]

I have lost my 0.332eth when I use Across procotol to bridge my eth from zks to other chain use metamask wallet? Who will compensate me? Can I ask metamask refund me? My address is 0x41e3A8766E0FF11eEF0c4D8eBe35a4F8d9772765,last transation hash is 0x912eff9e32127a10acfe325b2a9bcb8a848e401cdf08103ba5f21e9f2e446c24.

[simonazhang68]

Hey @coding-ice thanks for your report here. We have a fix for this issue that is rolling out with version 11.16.7

Edit: Actually you are reporting that you are seeing this on 11.16.7... We'll take a look!
I have lost my 0.332eth when I use Across procotol to bridge my eth from zks to other chain use metamask wallet? Who will compensate me? Can I ask metamask refund me? My address is 0x41e3A8766E0FF11eEF0c4D8eBe35a4F8d9772765,last transation hash is 0x912eff9e32127a10acfe325b2a9bcb8a848e401cdf08103ba5f21e9f2e446c24.

[MarcelCloud]

It would help if you also looked into the rabby and metamask sync issue. Rabby has more connection control and it affects interacting with metamask when we have to

[monokh]

Any ideas on what we could do to safe guard against bugs like these in future?

14 ETH lost on arbitrum, in only one scenario. Granted this is not solely on metamask, but it highlights what is at stake.

Many clients attach a chainId in eth_sendTransaction requests. If the chainId in the request doesn't match the chainId of the connected chain - metamask should reject or give a big warning. This common sense check would have likely prevented loss in the scenario that started this issue.

There should also be a warning when sending ETH with call data to a non existent contract. This again would have raised flags and prevented loss.

[simonazhang68]

Hey @coding-ice thanks for your report here. We have a fix for this issue that is rolling out with version 11.16.7
Edit: Actually you are reporting that you are seeing this on 11.16.7... We'll take a look!
I have lost my 0.332eth when I use Across procotol to bridge my eth from zks to other chain use metamask wallet? Who will compensate me? Can I ask metamask refund me? My address is 0x41e3A8766E0FF11eEF0c4D8eBe35a4F8d9772765,last transation hash is 0x912eff9e32127a10acfe325b2a9bcb8a848e401cdf08103ba5f21e9f2e446c24.

You have fixed this issue but who will refund my loss? I can't get my money back now!

[rosewinlet]

Many bugs for Metamask nowadays. I regconise these problems also:

• Chain switching problem like above. Switching chain is quite slow.
• Some RPC is suspended and metamask spins forever.
• The transaction was made successfully, but still the dapp connected with Metamask does not recognise, while other wallets like OKX, C98, ... are working very well. This problem just happens for some days.
• Some signing (only signing) but the token was transacted ( I've losted for more than 2000 usdt equivalent token).

Please take care these problems as soon as possible. We still believe in you!