[Bug]: Tx's are not updated to the last Recipient or tx Type, if I replace them using the same nonce, causing a missmatch between Etherscan & what MM displays
Describe the bug
Problem: when I update a tx from the Queue (being a Send or a Contract deployment) I can see that the data is not updated and the tx displays the old receiver, even though I've updated the receiver, or even change the tx for a Contract deployment
- Example changing the receiver and not updating (you can see the missmatch with Etherscan)
https://user-images.githubusercontent.com/54408225/185371181-776f7170-1e7d-4772-8740-9c440c63bf5a.mp4
- Example changing the Send tx for a Contract deployment (you can see the contract deployment on Etherscan, whereas on MM is displayed as a regular Send to the old receiver)
https://user-images.githubusercontent.com/54408225/185371316-f4484f65-1f98-4195-8002-fe0c7cbca32e.mp4
Steps to reproduce
- Unlock MM
- Enable Modify Nonce from Settings
- Click Send
- Modify Nonce and include the default nonce +1
- Set Low gas fees
- Confirm tx
- Perform another tx, now change the recipient (or deploy a contract)
- Modify Nonce being the same as 4
- Set Aggressive gas fees and proceed
- Click Send
- Perform any tx with default nonce
- Wait for all tx's to be confirmed
- Check tx details from 3, and check Etherscan details (See difference)
Error messages or log output
No response
Version
10.19.0
Build type
No response
Browser
Chrome
Operating system
Linux
Hardware wallet
No response
Additional context
No response
This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days. Thank you for your contributions.
We don't want this to be closed :)
This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.
This issue was closed because there has been no follow up activity in the last 45 days. If you feel this was closed in error, please reopen and provide evidence on the latest release of the extension. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.
This issue was closed because there has been no follow up activity in the last 45 days. If you feel this was closed in error, please reopen and provide evidence on the latest release of the extension. Thank you for your contributions.
According to the Ropsen site the test net has declared EOL December 2022, I will test this scenario against the Sepolia network
Issue was reproducible in Sepolia network and hence removed the stale label and reopening the issue.
Present in 12.23.0
Present in v13.1.0
Present in v13.3.0
Present in v13.8.0