Hello. guys I can’t buy kyte on uniswap. I confirm the trade, include the gas, then it’s pending, I check the etherscan and “Sorry, We are unable to locate this TxnHash” I have been waiting so long. what’s wrong with it?
Hello, @radek ! Welcome to the community! Do you still have issues?
I have the same issue in MetaMask for iOS on Polygon network.
I added Polygon as custom RPC as documented in docs matic network (/docs/develop/metamask/config-matic/) . This problem occurs regardless of Block Explorer used - I recently changed the Block Explorer URL to their new, faster polygonscan com and it still happens from time to time.
The problem looks like this:
Occasionally, after submitting a Smart contract interaction transaction, I end up waiting for a confirmation for a long time and it does not arrive.
In MetaMask’s Transaction History, its status shows up in orange (“Submitted”). When I tap on it and open it in block explorer, the explorer cannot find it (“Sorry, We are unable to locate this TxnHash”).
This has been happening especially frequently yesterday, when most of the Polygon’s RPC endpoints got overloaded and were returning errors (e.g.: twitter com /BlockVigil/status/1404469548653322243).
My suspicion (although I did not verify it by snooping on my MetaMask’s HTTPS traffic) is that MetaMask does not handle RPC errors correctly - I guess that even when it receives an error from the RPC endpoint, it still registers a transaction in its history log, while the blockchain network has not received it.
MetaMask ends up incrementing its transaction nonce and tracking a transaction that is not known on the actual blockchain. I don’t think this is a correct behavior. But I also don’t think it would be correct to withhold from incrementing the nonce and logging the transaction after every error - after all, the RPC endpoint that returned an error could have sent the transaction to the blockchain and fail after than, but before returning the response to MetaMask.
What I think MetaMask should be doing is, upon receiving an RPC error, it should block the user from issuing any new transactions (this might be a special transaction status on MetaMask’s side - e.g. “Submitting” denoted with red color, as opposed to current “Submitted” with orange), and query the status of the suspected failed transaction after waiting for a reasonable amount of time (with a few retries, too).
If the transaction cannot be queried after all the retries, it means the blockchain has not received it and the transaction must be removed from MetaMask’s history log, the nonce rolled back and an error must be displayed to the user, instructing them to try their action again.