eth_estimateGas returns "The execution failed due to an exception."

[Tbaut]

Before filing a new issue, please provide the following information.

• Parity Ethereum version: 2.2
• Operating system: Linux
• Installation: edit:built on master
• Fully synchronized: yes
• Network: kovan

Edit:
Running eth_estimateGas RPC against a full node returns "The execution failed due to an exception." :

Example:

2018-10-15 17:49:00   TRACE rpc  Request: {"id":204,"jsonrpc":"2.0","method":"eth_estimateGas","params":[{"to":"0x4a6e6c3868a279e1d9047b42c3fb356ff4680003","gasPrice":"0x1faa3b500","data":"0xa9059cbb000000000000000000000000004702bdcc3c7dbffd943136107e70b82702860000000000000000000000000000dfc93112abd2578503b667b95491b101281f2b"}]}.
2018-10-15 17:49:00   DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32016,"message":"The execution failed due to an exception."},"id":204}.

Message before edit, (not relevant for full nodes)

eth_getTransactionReceipt returns Timeout for On-demand query; 1 query attempts remain for query #0"
Running a full node on this branch connected as reserved-only to a light client (also on the same branch).

Here is the rpc trace, what happens is that I send a Tx and check for the request:

2018-09-28 09:20:04   TRACE rpc  Request: {"id":279,"jsonrpc":"2.0","method":"parity_postTransaction","params":[{"to":"0x4a6e6c3868a279e1d9047b42c3fb356ff4680003","data":"0x23b872dd00000000000000000000000000dfc93112abd2578503b667b95491b101281f2b000000000000000000000000004702bdcc3c7dbffd943136107e70b82702860000000000000000000000000000000000000000000000021e19e0c9bab2400000","gasPrice":"0x1836e2100"}]}.
2018-09-28 09:20:04   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x1","id":279}.
2018-09-28 09:20:04   TRACE rpc  Request: {"id":280,"jsonrpc":"2.0","method":"signer_confirmRequest","params":["0x1",{},"ptTf4igch#e"]}.
2018-09-28 09:20:04   TRACE rpc  Request: {"id":281,"jsonrpc":"2.0","method":"parity_checkRequest","params":["0x1"]}.
2018-09-28 09:20:04   DEBUG rpc  Response: {"jsonrpc":"2.0","result":null,"id":281}.
2018-09-28 09:20:04   DEBUG rpc  [Some(Num(280))] Took 11ms
2018-09-28 09:20:04   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x62151aed6d362d52d20634207c4c5adbb94bb427a0f1e813fae06333979d31f8","id":280}.
2018-09-28 09:20:04   TRACE rpc  Request: {"id":282,"jsonrpc":"2.0","method":"parity_chain","params":[]}.
2018-09-28 09:20:04   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"kovan","id":282}.
2018-09-28 09:20:04   TRACE rpc  Request: {"id":283,"jsonrpc":"2.0","method":"parity_chain","params":[]}.
2018-09-28 09:20:04   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"kovan","id":283}.
2018-09-28 09:20:04   TRACE rpc  Request: {"id":284,"jsonrpc":"2.0","method":"parity_checkRequest","params":["0x1"]}.
2018-09-28 09:20:04   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x62151aed6d362d52d20634207c4c5adbb94bb427a0f1e813fae06333979d31f8","id":284}.

Once parity_checkRequest answers with the Tx id, we check the receipt, and that's were things go south:

2018-09-28 09:20:04   TRACE rpc  Request: {"id":285,"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x62151aed6d362d52d20634207c4c5adbb94bb427a0f1e813fae06333979d31f8"]}.
2018-09-28 09:20:07   TRACE rpc  Request: {"id":286,"jsonrpc":"2.0","method":"net_peerCount","params":[]}.
2018-09-28 09:20:07   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x1","id":286}.
2018-09-28 09:20:12  Verifier #1 INFO import  Imported #8884968 0x781b…bba0 (0.29 Mgas)
2018-09-28 09:20:12   TRACE rpc  Request: {"id":287,"jsonrpc":"2.0","method":"net_peerCount","params":[]}.
2018-09-28 09:20:12   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x1","id":287}.
2018-09-28 09:20:15   DEBUG rpc  [Some(Num(285))] Took 11127ms
2018-09-28 09:20:15   DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32065,"message":"Timeout for On-demand query; 1 query attempts remain for query #0"},"id":285}.

Here is a similar trace with pip, on_demand and rpc.

[Tbaut]

Could be linked to #9133

[niklasad1]

@Tbaut

I don't understand what your main concern is, the most likely outcomes in my opinion are:

• The transaction has not been propagated to its peers (see Light client does not respond to eth_getTransactionReceipt request #9133)
• The default timeout query limit per peer is too short

¹ Most likely a combination of both

Are implying that the default query limit per peer is too short? You can change it what the CLI option --on-demand-retry-count it is 10 by default!

Have you tried this request with a bigger value such as 50 or something?

[Tbaut]

I've built the latest master, ran a full node and a light node connected to it.

Light node launched with parity-v2.2.0-unstable-bc056c4-20181009 --light --chain kovan --reserved-only --reserved-peers ./my-full-node-master --on-demand-retry-count 50 -l pip,on_demand,rpc

I also tried with --on-demand-retry-count 500 with the same result.

This time the Timeout for On-demand query happens on an eth_estimateGas though. I couldn't send a transaction.

Here is the gist pip, on_demand and rpc.

[niklasad1]

Thanks,

We should change the re-trying interval with a back-off mechanism i.e when a request fails then increase the time until the next request.

Maybe by exponential decaying?!

However, I'm still not sure the cause of this behavior.

I will fix #9133 first (or I have a PR ready soon for it) and then deal with this after!

[Tbaut]

This also happens when I do this RPC against a full node:

2018-10-15 17:49:00   TRACE rpc  Request: {"id":204,"jsonrpc":"2.0","method":"eth_estimateGas","params":[{"to":"0x4a6e6c3868a279e1d9047b42c3fb356ff4680003","gasPrice":"0x1faa3b500","data":"0xa9059cbb000000000000000000000000004702bdcc3c7dbffd943136107e70b82702860000000000000000000000000000dfc93112abd2578503b667b95491b101281f2b"}]}.
2018-10-15 17:49:00   DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32016,"message":"The execution failed due to an exception."},"id":204}.

[niklasad1]

I think #9756 should fix the timeout at least but the internal execution error thaẗ́'s a full-node issue :P

[ordian]

Looks like transact_virtual failed with Bad jump destination 0. Investigating further.