Warn when reading date from non-existing ancient blocks.

[tomusdrw]

Currently after warp sync not all blocks might be present, although you can see the latest state in the UI.

This might be especiall frustrating for developers, since RPC is just simply not returning data for such blocks.

Example:
Fetching all the logs for particular address can render an empty list even though there are clearly blocks with logs out there.

Proposal:

1. Display a warning if such query is detected (blockNumber < latestBlock && block not found)
2. Return a "ancient block missing" RPC error.

[epheph]

This issue is really critical for Augur, which sync's the blockchain via a series of getLogs, making the assumption that blocks prior to getBlock("latest").number are available. To illustrate the issue outlined above, here is an inspection of CryptoKitties Birth events from a recently warp-sync'd parity node (warp-barrier: 0x5f8521):

$ curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[ {
"fromBlock":"0x500000",
"toBlock":  "0x5f853e",
"address":"0x06012c8cf97bead5deae237070f9587f8e7a266d","topics":["0x0a5311bd2a6608f08a180df2ee7c5946819a649b204b554bb8e39825b2c50ad5"]} ],"id": 74}' localhost:8545 | jq .result[].blockNumber | uniq -c
      1 "0x5f8523"
      2 "0x5f8527"
      2 "0x5f8528"
     13 "0x5f852b"
      2 "0x5f852d"
      3 "0x5f852e"
      7 "0x5f852f"
      2 "0x5f8530"
      3 "0x5f8532"
      2 "0x5f8533"
     18 "0x5f8535"
      1 "0x5f8536"
      2 "0x5f8537"
      6 "0x5f8539"
     14 "0x5f853a"
     16 "0x5f853c"
      1 "0x5f853d"
      1 "0x5f853e"

There were a great number of events between 0x500000 and 0x5f8523, but they were simply omitted from this getLogs call, with no indication that anything went wrong inside Parity. Running this query again later, after ancient blocks downloaded, would return different results.

We will add a section to our README advising users not to use Parity with warp-sync (or to use warp-sync only with a specific -warp-barrier prior to any blocks that contain relevant logs), but changing this behavior in Parity seems like the right thing to do. Ideally, an error would be returned if Parity could not satisfy a request, instead of a silent or partial failure.

[udoprog]

I'll echo my comment on a duplicate issue (#9542) I opened here instead:

After I've set up a new mode with warp and I try to query for historical logs, I get incomplete results. IIUC this is expected since parity by default prunes historical data. However, RPC clients can easily make the assumption that eth_getLogs Returns an array of all logs matching a given filter object. With emphasis on all. An application written with this assumption is very likely to be broken.

We should consider returning an error instead if logs for a queried-for block is not available.

Relates to #9541

[epheph]

@udoprog The issue isn't that it "prunes" this data in warp mode, the issue is that it has not yet back-filled the data (even though much newer blocks DO have this data). This issue is specific to warp-mode. If you wait long enough, those blocks and logs will become available to your warp-sync'd parity node.

Your conclusion is correct, though: "We should consider returning an error instead if logs for a queried-for block is not available."

[tomusdrw]

@seunlanlege wasn't that done already?

[seunlanlege]

yup in #9475