ethers.js
ethers.js copied to clipboard
Failed view function calls with empty return data don't throw an error
Ethers Version
5.6.8
Search Terms
return data, mocha, view functions, hardhat
Describe the Problem
We (Hardhat) added a data field to our returned errors so that ethers can use it to interpret the error reasons.
This seems to work pretty well, except in one scenario: view functions that fail without an error reason (empty return data). This can happen if a require(false) statement is hit (notice the lack of reason string). This also happens for out of gas errors and for assert(false) statements before panic codes were added in solidity 0.8.0.
The problem is that, in these scenarios, Hardhat returns a 0x string as the data, and this seems to confuse ethers and make it think that there was no error. Adapting the return data to be an empty string (or to remove the property completely from the response) fixes the issue, but we believe it's more consistent to always return something, and to return 0x when the return data is empty. This is consistent with, for example, how eth_getCode returns 0x when there's no code in an address.
Oh, and this only happens for static calls (and I think also for gas estimates? I'm not sure right now), not for normal transactions.
I can expand on this if necessary, but hopefully this is enough.
Code Snippet
No response
Contract ABI
No response
Errors
No response
Environment
node.js (v12 or newer), Hardhat
Environment (Other)
No response
Thanks, I'll look into this right away.
I think 0x is probably the correct thing to return, but it does mean something specific. The data 0x means that there were no bytes returned (which is absolutely the case in getCode when there is no bytecode). I'm not certain what happens when Geth hits an out-of-gas, I'll look into that too. I'll compare Hardhat to Geth too.
A staticCall should not use gas estimation, but I'll double check. :)
Thanks!
A
staticCallshould not use gas estimation, but I'll double check. :)
Oh, sorry, I meant in the case that the estimateGas calls also used the return data (we include return data for those too).
Hi @ricmoo, were you able to look into this?
I understand this issue now, and this can be addressed in v5 I believe. It will only work through the Contract interface though. The example in #3605 makes things much clearer. :)
This shouldn’t be an issue in v6. :)
I’ll look into this for a patch release for 5.7.