estimateGas() fails completely if high GAS values are required.

[soundreactor]

• Version: 4.2.1
• Python: 3.6
• OS: osx

i can't estimateGas() on locally signed transaction. (before OR after i sign it). for example this fails miserably:

contract_instance = w3.eth.contract(address=test_contract, abi=contract_abi)
contract_txn = contract_instance.functions.createP(
    input_pid,
    input_data,
    input_newowner,
    input_message,
).estimateGas()

HOWEVER: if i set gas manually to 300000 the exact same transaction succeeds without erros. so i know the transaction is actually valid. so why is the gas estimation not working? is there a limit ?

contract_instance = w3.eth.contract(address=test_contract, abi=contract_abi)
contract_txn = contract_instance.functions.createP(
    input_pid,
    input_data,
    input_newowner,
    input_message,
).buildTransaction({
    'chainId': test_chainid,
    'gas': 300000,
    'nonce': nonce,
})

#the rest of the code
signed_txn = w3.eth.account.signTransaction(contract_txn, private_key=test_pk)

#this also does not work. throws errors !!
#gas_estimate = w3.eth.estimateGas(signed_txn)
#print(gas_estimate)
#exit()

try:
    sendTransactionResult = w3.eth.sendRawTransaction(signed_txn.rawTransaction)
except ValueError:
    print("error:"+sendTransactionResult)

Traceback (most recent call last):
  File "C:\xampp\htdocs\web_limited\ETH\ci_createP.py", line 72, in <modul
e>
    'nonce': nonce,
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\web3\contract.py", line 1105, in buildTransaction
    **self.kwargs)
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\web3\contract.py", line 1363, in build_transaction_for_function
    prepared_transaction = fill_transaction_defaults(web3, prepared_transaction)

  File "functoolz.pyx", line 232, in cytoolz.functoolz.curry.__call__
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\web3\utils\transactions.py", line 43, in fill_transaction_defaults
    default_val = default_getter(web3, transaction)
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\web3\utils\transactions.py", line 27, in <lambda>
    'gas': lambda web3, tx: web3.eth.estimateGas(tx),
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\web3\eth.py", line 280, in estimateGas
    [transaction],
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\web3\manager.py", line 106, in request_blocking
    raise ValueError(response["error"])
ValueError: {'code': -32000, 'message': 'gas required exceeds allowance or alway
s failing transaction'}
�

[carver]

the exact same transaction succeeds without errors.

In your second example, you are only creating the transaction in python. Try sending it to your node with transact, like:

txn_hash = contract_instance.functions.createP(
    input_pid,
    input_data,
    input_newowner,
    input_message,
).transact({
    'chainId': test_chainid,
    'gas': 300000,
    'nonce': nonce,
})

Finally, even if your transaction gets included in a block, it might not have succeeded. Transactions that raise errors via throw or revert are also mined. So check whether it's successful with:

receipt = w3.eth.waitForTransactionReceipt(txn_hash)
assert receipt.status == 1

---

Side note: you can add triple back-ticks to start and end code-blocks in a more readable form, like: `` code here` ```

[soundreactor]

@carver yes i know. this is not the full code. i am 100% sure it succeeded im using the mist wallet to check if the contract values have been updated. and i use https://ropsten.etherscan.io/ to see the progress. but thanks for your concern anyways. i comment part of the code that estimates gas and its works otherwise it throws the error..

[carver]

There is no limit in Web3.py on the amount of gas that can be estimated. The error is being returned by the node, though, so I can't say anything about what the node is capable of.

---

Since the problem doesn't appear to be specific to Web3.py, I'm closing the issue. But feel free to continue discussing here. One alternative to consider is https://ethereum.stackexchange.com

You will get better & faster answers if your question has a minimal, complete, and verifiable example (in this case, that means including the contract source): https://stackoverflow.com/help/mcve

[soundreactor]

@carver okey thanks for clearing that up. im using infura. so i guess they don't like estimating expensive functions.

[soundreactor]

@carver i guess one issue here could be the error handling in web3 so others don't have to come knocking on the wrong door.

[nazariyv]

@carver i guess one issue here could be the error handling in web3 so others don't have to come knocking on the wrong door.

why would infura work with web3.js but not web3.py (for estimating gas)?

I am having the same issue right now. Asking because I am thinking about using Alchemy, but also thinking if Infura would be the real culprit, then (1) will Alchemy help, (2) why would web3.js work fine.

[carver]

The first place I would check is that you're estimating gas with exactly the same transaction in both js and py.

[caldaryx]

has this been resolved? Same issue here. Threshold appears to be 38400 gas.

*just want to add its not a node/RPC issue as i've tried several including local node.

[blin17]

having the same issue here

[caldaryx]

having the same issue here

For me the issue was resolved after specifying the "from" value. Wish there was an actual error message for it, would have saved a lot of time.

[kratatomi]

Hi, same error here in SmartBCH. While Metamask estimates the gas limit correctly, web3py fails.

[fselmo]

@kratatomi I would check that all parameters of the transaction are filled including the from field. Also, not all chains / nodes are built equally. Given how specific these errors are, it's likely that they are provider-specific. I'd suggest anyone landing on this page to post your particular issue in the python community Discord (ideally with markdown syntax and not a screenshot) and if it does turn out to be a bug we can go from there and track it either here or with a new issue.