Support reason string

[4000D]

According to Solidity 0.4.22 release, we can specify the reason in revert or require function.

After web3 1.0 alpha (or stable) version released, should plan to support reason string.

[kikoncuo]

Any updates?
That'd be nice, right now, the current message is not helpful at all.

[kikoncuo]

Quick update, it should work, we are missing the implementation on Geth and Parity, but ganache-cli client (>= 6.1.3) has it, you can test it with truffle v5.0.0

[lastmjs]

Is this the reason there is no error message in the transaction data when using require? I have many requires with error messages, and when they fail I can't see anything in the transaction info on Etherscan about the reason. Remix shows the error when I use the JavaScript VM, but not on the test network. Is it true that the transaction information just doesn't have the error message yet when using require?

[kikoncuo]

Seems like it, Ganache and Remix VM have it, Geth or Partity, don't.

[abhayks1]

This is a very nice feature. Will save time lot of time while debugging.

[nivida]

@abhayks1 Yep, it is on my todo list and should get released in v1.0.0-beta.39 or -beta.40.

[a-thomas]

Any updates? It seems that we are already at beta.41

[CryptoKiddies]

A friendly ping, is error message handling still in the works?

[nivida]

@GeeeCoin We do currently discuss the steps until the stable release here in this issue #2684 feel free to join the discussion!

[pcowgill]

This issue should be removed from milestone 1.0 or that milestone should be renamed, now that this has the 2.x label.

Also, it should be moved from the 1.0 project to the 2.0 project.

[pcowgill]

But also, it's probably worth creating a parallel issue to add this into the stable 1.x branch, since this is one of the most requested features for web3.js.

[gorgos]

How does this not have higher priority? This is so important.

Every time one gets a Tx reverted with Web3 and doesn't know why, the only option is to comment out a single revert in the called method, re-deploy, get to the correct previous contract state again and see if it got reverted again. You can imagine what a pain this is for contracts with complex states and lots of reverts.

[sohkai]

For eth_calls, perhaps it makes sense to have ethers provide the decoding since all the output is formatted through ethers's AbiCoder anyway? (ethers-io/ethers.js#596)

[eloudsa]

Any new status of this request?
Is there any plan to support reason string in short-term?
I fully agree with @gorgos. This request is really important.
At least to display an understandable error message to our end-users.

[liamaharon]

FYI the code Etherscan uses to get revert reasons is open source
https://twitter.com/rstormsf/status/1171378476982521865
https://github.com/pertsev/web3_utilz/tree/master/revert%20reason

[nivida]

We have implemented this feature for 1.x and will release it on the next minor release. We will implement this feature also for 2.x and I'm closing this issue for now because we will anyways synchronize the existing features between 1.x and 2.x later.

[pcowgill]

@nivida Do you have a rough estimate for when the minor release with this change might be ready? Thanks!

[pcowgill]

It looks like this is the release to keep an eye on, right?
#3315

[nivida]

@pcowgill Yep, it is and I will release it today. :)

[gorgos]

@nivida Does it work?

web3.eth.handleRevert = true gives me (with sendSignedTransaction) something like this without message:

{ Error: Transaction has been reverted by the EVM:
   {
     ...
     "status": false,
     ...
   }
       at Object.TransactionError (.\node_modules\web3-core-helpers\src\errors.js:63:21)
       at Object.TransactionRevertedWithoutReasonError (.\node_modules\web3-core-helpers\src\errors.js:75:21)
       at .\node_modules\web3-core-method\src\index.js:448:48

Am I using it correctly?

[nivida]

@gorgos Yes, this is the currently expected behaviour for sendSignedTransaction. The revert handling got implemented for eth.call and eth.sendTransaction as documented here but not for the eth.sendSignedTransaction call. We will extend the revert handling with decoding of the passed signed transaction for a later request for the revert reason string. I apologize for not implementing this at the same time as well and will create a related issue now.

[nivida]

As an addition the workaround:
You are able to get the revert reason string also without decoding implemented. Just store the txOptions before you sign it and execute eth.call with it in the error case.