pending for defaultBlock causes issues during estimateGas

[iFA88]

Greetings!

I have tried the following nodes:
Parity-Ethereum/v2.0.0-beta-6eae372-20180717/x86_64-linux-gnu/rustc1.27.1
Parity-Ethereum/v2.0.1-beta-e7dc0be-20180726/x86_64-linux-gnu/rustc1.27.2

where I have the same issue for eth_estimateGas when I use pending for defaultBlock parameter:

-> {"jsonrpc": "2.0", "params": [{"to": "0xa8711bf8f25e9d87498777e4b3b651f6e811cc7d", "from": "0xa8711bf8f25e9d87498777e4b3b651f6e811cc7d", "value": "0x2386f26fc10000", "data": "0x"}, "pending"], "method": "eth_estimateGas", "id": 1}
<- {"jsonrpc":"2.0","error":{"code":-32000,"message":"This request is not supported because your node is running with state pruning. Run with --pruning=archive."},"id":1}

This happens not every time, about 1/5 times. Maybe it happens during the block import process.

When it works then I receive:

-> [{"to": "0xa8711bf8f25e9d87498777e4b3b651f6e811cc7d", "from": "0xa8711bf8f25e9d87498777e4b3b651f6e811cc7d", "value": "0x2386f26fc10000", "data": "0x"}, "pending"], "method": "eth_estimateGas", "id": 1}
<- {"jsonrpc":"2.0","result":"0x5208","id":1}

[iFA88]

Not only the eth_estimateGas are affected, eth_getLogs and every method who can put defaultBlock parameter is affected.
If I use latest they produces the same error.

[Tbaut]

I could reproduce the problem.

If I use latest they produces the same error.

I did not reproduce with "latest" however. In general @iFA88, for a non mining node, "pending" will be the same as "latest" since your node is not creating any block.

[Tbaut]

Can you have a look @tomusdrw ?

[iFA88]

I have forgot to say that I use the following parameters:

--no-persistent-txqueue --jsonrpc-server-threads 8 --no-ancient-blocks --min-gas-price=10000000 --tx-queue-mem-limit=4096 --tx-queue-size=256000 --reseal-on-txs=all --force-sealing --rpcport 8548 --port 30306 --no-ws --no-secretstore --cache-size 2048

[Tbaut]

That's indeed important as --force-sealing lets you take into account the latest transactions. This is most probably a bug.

[tomusdrw]

@iFA88 I checked the code paths for latest resulting in the same error, but it's not clear for me how this could happen (if ever).

Could you provide -lrpc=trace,client=trace,miner=trace logs from the period when that happens for you using latest?

[iFA88]

Ofc!
The request is on: 2018-08-08 13:00:18

https://www.fusionsolutions.io/doc/log.txt

[tomusdrw]

@iFA88 Thanks! Although the request there is for pending block, do you have the same logs for latest as you mentioned it also happens in such case.

The logs highlighted some other issue with the code though, I will update #9310

[iFA88]

Yeah, i'm trying to reproduce the error for latest but unsuccessful.

[iFA88]

Hi! I would like to report, that the bug is still available.

I'm using Parity-Ethereum/v2.2.7-stable-b00a21f-20190115/x86_64-linux-gnu/rustc1.31.1 fresh resynced with the following parameters:

--infinite-pending-block --no-persistent-txqueue --jsonrpc-server-threads 8 --no-ancient-blocks --min-gas-price=10000000 --tx-queue-mem-limit=4096 --tx-queue-size=256000 --reseal-on-txs=all --force-se
aling --base-path /mnt/node-1/fastEth --rpcport 8548 --port 30306 --no-ws --no-secretstore --cache-size 2048 --log-file /own/log/nodes/fastEth/parity_eth.log

Request:

-> {"jsonrpc": "2.0", "params": [{"to": "0xc937f5027d47250fa2df8cbf21f6f88e98817845", "from": "0xa8711bf8f25e9d87498777e4b3b651f6e811cc7d", "value": "0x0", "data": "0xa9059cbb000000000000000000000000610e3b4e804b367c182c5fc4d65d09c0897233890000000000000000000000000000000000000000000000000000000005f5e100"}, "pending"], "method": "eth_estimateGas", "id": 1}
<- {"jsonrpc":"2.0","error":{"code":-32000,"message":"This request is not supported because your node is running with state pruning. Run with --pruning=archive."},"id":1}

With earliest is the same result. With latest works and calculates the estimated gas amount.

If i want to send several transactions to the same contract I can not get how much gas should i attach it or even it throws/reverts or not.

[tomusdrw]

Indeed we don't have atomicity when we try to work on the pending state, so:

ensure_pending_block_exists();
call_into_pending_state();

This code works most of the time, but in case you have --reseal-on-txs=all it's very likely that in between the calls we will attempt to recreate the pednign state and it's going to be temporarily unavailable.

We should replace the pending RPC apis with something that allows us to get a copy of pending state and then call into it so that it's not susceptible to races like that.
(on the second though the RPC might be fine it might be issue with internal miner implementation)

[seunlanlege]

closed by #11127