Skip to content
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

Support reason string #1707

Closed
4000D opened this issue Jun 15, 2018 · 22 comments
Closed

Support reason string #1707

4000D opened this issue Jun 15, 2018 · 22 comments
Assignees
Labels
2.x 2.0 related issues Enhancement Includes improvements or optimizations

Comments

@4000D
Copy link

4000D commented Jun 15, 2018

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
Copy link

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

@kikoncuo
Copy link

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
Copy link

lastmjs commented Nov 3, 2018

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
Copy link

kikoncuo commented Nov 5, 2018

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

@abhayks1
Copy link

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

@nivida
Copy link
Contributor

nivida commented Jan 25, 2019

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

@a-thomas
Copy link

a-thomas commented Feb 4, 2019

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

@CryptoKiddies
Copy link

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

@nivida
Copy link
Contributor

nivida commented Apr 17, 2019

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

@nivida nivida added the 2.x 2.0 related issues label Jun 20, 2019
@pcowgill
Copy link

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
Copy link

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
Copy link

gorgos commented Aug 12, 2019

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
Copy link

sohkai commented Sep 1, 2019

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
Copy link

eloudsa commented Oct 25, 2019

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
Copy link

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
Copy link
Contributor

nivida commented Dec 6, 2019

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.

@nivida nivida closed this as completed Dec 6, 2019
@pcowgill
Copy link

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

@pcowgill
Copy link

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

@nivida
Copy link
Contributor

nivida commented Jan 27, 2020

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

@gorgos
Copy link

gorgos commented Jan 28, 2020

@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
Copy link
Contributor

nivida commented Jan 28, 2020

@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
Copy link
Contributor

nivida commented Jan 28, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.x 2.0 related issues Enhancement Includes improvements or optimizations
Projects
None yet
Development

No branches or pull requests