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

estimateGas errors when using defaultAccount #3188

Closed
mrkurosawa opened this issue Nov 7, 2019 · 13 comments
Closed

estimateGas errors when using defaultAccount #3188

mrkurosawa opened this issue Nov 7, 2019 · 13 comments
Labels
1.x 1.0 related issues Needs Clarification Requires additional input

Comments

@mrkurosawa
Copy link

Before send tokens from to address, i need calculate estimateGas, but after last update it starts to throw error:

UnhandledPromiseRejectionWarning: Error: Returned error: gas required exceeds allowance (9948620) or always failing transaction

Error happens when ctApprove.methods.transferFrom( fromAccount, toAccount, balanceIncome ).estimateGas() calls.
How can i fix this problem?

var contractAddress = 'some token contract address'; 
    var fromAccount = 'some address in my wallet from i need send tokens';
    var toAccount = 'main address i need send tokens to';
    var ctApprove = new web3.eth.Contract( JSON.parse( fs.readFileSync( `${__dirname}` + '/***.abi', 'utf-8' ) ), contractAddress, { 
        'defaultAccount': toAccount,
    } );
    ctApprove.methods.balanceOf( fromAccount ).call()
        .then( balanceIncome => {
            ctApprove.methods.transferFrom( fromAccount, toAccount, balanceIncome ).estimateGas() // here error
                .then( estGas => {
                    web3.eth.getGasPrice()
                        .then( estGasPrice => {
                            console.log( {
                                'gas': estGas,
                                'gasPrice': estGasPrice,
                            } );
                        } );
                } );
    } );
@cgewecke
Copy link
Collaborator

cgewecke commented Nov 7, 2019

@mrkurosawa Could you list your:

  • ethereum client and version (e.g geth? ganache?)
  • web3 version

@mrkurosawa
Copy link
Author

ethereum Geth/v1.9.6 go1.11.5
web3 1.2.2

@kvhnuke
Copy link

kvhnuke commented Nov 7, 2019

same as #3175 I believe, MEW reverted back to 1.2.1 due to this issue

@cgewecke
Copy link
Collaborator

cgewecke commented Nov 7, 2019

@kvhnuke

I think @mrkurosawa might have a slightly different issue because their estimateGas looks like the source of the error. They are not invoking a method using a perfect estimate (as in #3175).

Two questions:

  • To be clear - are you sure you're affected by Using gas value provided by estimateGas triggers error even though tx succeeds #3175 e.g you are not adding any extra gas to your estimates?
  • Could you point me in the direction of any public test suites you have? We have recently introduced a CI job that can install web3 from a branch into a target and run their tests as a sanity check. MEW would be a great addition to that.

@cgewecke
Copy link
Collaborator

cgewecke commented Nov 7, 2019

@mrkurosawa Have just added a very simple estimateGas test case to our CI (also using Geth 1.9.6) and it's passing. Could you share a reproducible example so I can investigate further?

@mrkurosawa
Copy link
Author

web 1.2.1 same error. I tried just rpc call eth_getBalance with data generated by encodeABI, but have same error. Looks like it's geth 1.9.6 problem. Because before update everything worked fine.

@mrkurosawa
Copy link
Author

Updated ethereum to 1.9.7 and same error, lol.
Looks like ABI string is right, i checked both addresses and value: everything is ok. Param 'to' in eth_getBalance just contract address am i right? So only 'to' and 'data' params is required there. Dont understand why it's throwing error.

@cgewecke
Copy link
Collaborator

cgewecke commented Nov 8, 2019

@mrkurosawa

Looks like it's geth 1.9.6 problem

If you can isolate it to geth it would be valuable to report it to them. Maybe there's already something in the issues there as well. But it could also be that estimateGas is hitting a revert statement while running the code because something's wrong with the address or another contract state issue.

gas required exceeds allowance (9948620) or always failing transaction

This error message is generated by Geth fwiw, not web3.

If you discover this isn't directly caused by Web3 feel free to close, otherwise will leave open for time being.

@cgewecke cgewecke added 1.x 1.0 related issues Needs Clarification Requires additional input labels Nov 8, 2019
@mrkurosawa
Copy link
Author

Well, it's seems like web3 problem or something, because problem solved, when i rename 'defaultAccount' param to 'from' here:

var ctApprove = new web3.eth.Contract( JSON.parse( fs.readFileSync( `${__dirname}` + '/***.abi', 'utf-8' ) ), contractAddress, { 
        'defaultAccount': toAccount,
    } );

Now everything works good, but i am interested why this happened? i thought 'from' and 'defaultAccount' is same thing.

@cgewecke
Copy link
Collaborator

cgewecke commented Nov 8, 2019

@mrkurosawa Thanks for solving.

Looking at the docs here, I don't see estimateGas listed as one of the defaultAccount enabled methods.

But that doesn't work very well in the kind of flow that you've set up. We should look into this and see if it can be improved.

@cgewecke
Copy link
Collaborator

cgewecke commented Nov 8, 2019

Mmm, I looked in eth-contract and it seem like this should be working as expected... needs more investigation.

https://github.com/ethereum/web3.js/blob/22df832303e349f8ae02f0392e56abe10e1dfaac/packages/web3-eth-contract/src/index.js#L799-L809

@cgewecke cgewecke changed the title Error: Returned error: gas required exceeds allowance (9984651) or always failing transaction estimateGas errors when using defaultAccount Nov 8, 2019
@mrkurosawa
Copy link
Author

Yep i just tested traffic with tcpdump and discover in first case with 'defaultAccount' it's sending data without 'from' param and it leads to the error obviously, but when i rename it to 'from', everithing works good. So it's my fault, only one thing i dont understand, why it worked without errors earlier?

@mrkurosawa
Copy link
Author

Anyways it's solved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.x 1.0 related issues Needs Clarification Requires additional input
Projects
None yet
Development

No branches or pull requests

3 participants