eth_getLogs and eth_getBlockByNumber failing on pruned DB

[yorickdowne]

System information

Erigon version: v2021.10.01

OS & Version: Ubuntu 20.04

Commit hash : ef80fd5

Prune: prune="--prune=htc --prune.r.before=11184524"

Behaviour

eth_getLogs call returns on error on block 11185311; eth_getBlockByNumber returns "null" for it and its parent and child block.

curl http://localhost:8547 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"address": "0x00000000219ab540356cBB839Cbe05303d7705Fa", "fromBlock": "0xAAA98C", "toBlock": "0xAAACA0"}],"id":1}'

{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"block not found 11185311"}}

curl http://localhost:8547 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xAAAC9E", false],"id":1}'

{"jsonrpc":"2.0","id":1,"result":null}

curl http://localhost:8547 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xAAAC9F", false],"id":1}'

{"jsonrpc":"2.0","id":1,"result":null}

curl http://localhost:8547 -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xAAACA0", false],"id":1}'

{"jsonrpc":"2.0","id":1,"result":null}

This pattern of not returning data for eth_getBlockByNumber is broader, I have not determined the edges. "latest" works and "0x1" works, both return data.

[AskAlexSharov]

I understand what is reason:

• we recently added pruning of Senders - it's inside h
• and if no senders we do return "no block", but I think it's fine that no senders - senders can be recovered on the fly - just you will pay CPU
• so, if you will see high CPU usage at this block numbers - then also increase "pruning distance" of character h

Please try branch: no_senders_is_fine

[yorickdowne]

Perfect, no_senders_is_fine does exactly what I need. Thank you! I am looking forward to seeing that feature in a future release. Closing issue.

[AskAlexSharov]

I said wrong, senders belong to “t”, not “h”.

[yorickdowne]

Thank you for clarifying. The No Senders branch worked, and since the consensus client (“beacon”) gets the data only once, when it is syncing deposits, the additional CPU load doesn’t hurt.