delete 'shallow' fh eth blks on rpc+ingestor start

[sduchesneau]

when launching grpah-node with an ingestor on an eth chain with an RPC provider (i.e. not firehose), this will delete the 'shallow' blocks in chainX.blocks, so they do not cause issues to the RPC provider.

It only runs on ethereum chains where firehose is not used and when ingestor is active.

[sduchesneau]

@leoyvens I am not quite sure how to delete the shallow blocks in a background thread without causing a race condition with the indexer...
So I have two questions:

1. Do you believe there are risks associated with the deletion while the ingestor will be ingesting more blocks ?
2. If there are none, could you give me some pointers on what to use for this ? :)

[leoyvens]

Good thinking that there could be a race condition with the ingestion. One possibility would be that blocks are deleted within the reorg threshold, and therefore should be re-ingested, but due to a race condition the ingestor believes they are already ingested and doesn't reingest. I checked and I think we're safe, ultimately because the missing parent query in fn missing_parent always checks that all the necessary parents are present, so if some are suddenly deleted, they will be reingested.

But here is another idea, what if we only cleanup blocks within the reorg threshold? That would make the query much cheaper, as ultimately less blocks need to be deleted. So it would be able to use the existing index on the block number, then we wouldn't need the migration and also we wouldn't need to run the cleanup in the background.

[leoyvens]

How about:

if let Some(head) = store.chain_head_block(&&store.chain)?

[leoyvens]

Check for overflow. Also I'd give some slack here so we don't have to worry about off by one, race conditions or whatever, maybe use 2 * ENV_VARS.reorg_threshold.

[leoyvens]

I did a review of the code to check if it's safe to keep the final blocks ingested by Firehose in the cache when switching to RPC. The concern being that those blocks could have a data column in a format incompatible with what the RPC block stream accepts. It really is incompatible, but the RPC block stream is robust to this because:

• In chain_store.rs, the data json value is returned only in fn ancestor_block and fn blocks.
• The RPC block stream uses fn ancestor_block only for non-final blocks.
• When it uses fn blocks, it ignores parsing errors:
  

  graph-node/chain/ethereum/src/ethereum_adapter.rs

  Line 1271 in aeacbeb

  .filter_map(|value| json::from_value(value).ok())

So while the situation with json formats for the data field is a bit of mess, it seems deleting just the blocks within the reorg threshold will work.

If my review is wrong and something complains of deserialization failure, we can re-revisit this and resort to the alternative of truncating the whole blocks table when a switch from Firehose to RPC is detected.