-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixed messaging on transaction confirmation/failure #6951
Comments
@wbt could you email your state logs to [email protected] to help us investigate? cc @tmashuang |
Unfortunately not, but I can check specific values in the JSON if you'd like. |
did the transaction actually go through? what does Etherscan tell you about the tx? could you send just the blob in your state log that describes this tx and redact whatever info you're not comfortable sharing? we're not able to reproduce as-is |
It was on a private chain, so it's not on Etherscan, despite all the links pointing to check out the transaction on Etherscan (Issue #5631). The transaction display doesn't make it clear what exactly the transaction was attempting to do, and it was part of a set of >100. Reviewing the events triggered on chain, I haven't yet noticed one missing, so it's possible that it went through, but it seems almost as likely that I might just not have noticed what exactly is missing. This was associated with attempting to set up steps to reproduce for #6949 and those steps to reproduce might still work to get this one reproducing. Unfortunately, I haven't validated that yet and don't have the time to do so at this moment nor in the next few days, but anybody else in this open-source community is welcome to try. Setting the gas amount to a lower value than the gas actually required for a transaction (but probably over the minimum transaction gas amount) early in a set of transactions seems likely to be a key step in reliably triggering a failure, when this might be observed. Per the records below, it looks like I changed the gas limit from 132775 to 52775 on a transaction where the estimated gas consumption (hidden value) was 88517. Out-of-gas also seems consistent with why the gas limit = gas used in the screenshot above. The inconsistency within MetaMask's messages signal pretty strongly to me that this is definitely a bug somewhere in MetaMask, even if there may be other factors contributing to why the transaction failed in the first place (if indeed it did fail). The JSON for that transaction from state logs is below, with a few annotations on hex values for readability. Redacted values with the same redaction variable name have a consistent value; offsets are made explicit where applicable.
|
I am going to close this and link another issue that is more high level which involves tx failures, subsequent transactions, and tx activity as a whole, #9053. |
If you have a sequence of several transactions and an early one fails, once you finish approving the others so you can see the buried failure message, it may not be clear whether it failed or not.
For example: Did this transaction fail, as indicated by the red "Failed" label, or succeed, as indicated by "Transaction confirmed" on the bottom?
I'm not sure. Also, if it did fail, why? Hovering over the "Failed" label, even for a long while, does not produce any tooltip explaining the error, as it sometimes does. My best guess is Out Of Gas, but MetaMask prevents me from seeing for sure.
(Finally, why the horizontal scrollbar? It's just all blank white space to the right. At the top, I can see more of a wide balance figure, but the most siginficant digits on the left end of that balance are still cut off.)
Environment:
The text was updated successfully, but these errors were encountered: