Non-descriptive error while simulating TX using Metamask

[dumikau]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

Daemon:  1.30.0+mainnet+git.12e6428+api1.5.0
Local: lotus version 1.30.0+mainnet+git.12e6428

Repro Steps

1. Simulate a transaction with insufficient gas
2. Observe the error message in the console

Describe the Bug

We had a few ppl try to send TXs via MetaMask and them failing during simulation with a nondescript RPC error like this:

Error: missing revert data (action="estimateGas", data=null, reason=null, transaction={ "data": "0x299a1d770 [...] 000000000", "from": "0x2224 [..] 5D96", "to": "0xd6Ab8e72dE3742d45AdF108fAa112Cd232718828" }, invocation=null, revert=null, code=CALL_EXCEPTION, version=6.13.4)

And it turns out that the reason was just that the users were low on FIL & didn't have enough to pay gas. As soon as they added some, it went through

We'd usually expect MetaMask to handle this gracefully by bringing up the TX popup and showing the user that they're low on gas in this case, like it does on Eth Mainnet. I suspect that the reason it doesn't on FEVM is that the above error isn't the usually expected RPC Error: err: insufficient funds for gas

Logging Information

Not applicable

[rvagg]

missing revert data; I'm going to cross my fingers and suggest that #12553 and #12675 might deal with this. As of lotus 1.31.0 we'll be spitting out a "data" field with some of these calls that eth tooling should be able to decode and figure out what the problem is. I don't know that it actually solves this but I'd love to be able to replicate this to see what it's doing under the hood.