While doing backfill testing, I noticed this interesting bug:
INFO [06-23|06:41:05.237] Backfill: initial positions chain=2730 indexer=2729 headGap=1
INFO [06-23|06:41:07.057] Imported new potential chain segment number=2731 hash=6df850..01dd93 blocks=1 txs=0 mgas=0.000 elapsed="443.46µs" mgasps=0.000 dirty=0.00B
INFO [06-23|06:41:07.070] Imported new potential chain segment number=2732 hash=6d203c..06bfcf blocks=1 txs=0 mgas=0.000 elapsed="162.698µs" mgasps=0.000 dirty=0.00B
INFO [06-23|06:41:07.077] Extend chain add=2 number=2732 hash=6d203c..06bfcf
INFO [06-23|06:41:07.077] Chain head was updated number=2732 hash=6d203c..06bfcf root=52b594..5c6b10 elapsed="129.118µs"
INFO [06-23|06:41:07.077] Writing state diff "block height"=2732 worker=1
The Extend chain message comes from the reorg code, though this doesn't appear to be a reorg based on competing block candidates at the same height, but rather triggered by a second potential chain segment (2732) being imported before the chain head is updated from the first imported segment (2731). This leads to extending the chain by two blocks (2731:2732) in one step, and the statediff code only receives a single event related to the chain head update, not at block 2732.
This gap will not be caught by the gap filling code unless the process is restarted, since that code currently only runs once at startup.
This would be caught and corrected eventually if we set that code to run at an interval instead, but it is probably better to detect this condition as it happens--we have all the information we need to do so--and trigger statediffing of the intervening blocks.
While doing backfill testing, I noticed this interesting bug:
The
Extend chain
message comes from thereorg
code, though this doesn't appear to be a reorg based on competing block candidates at the same height, but rather triggered by a second potential chain segment (2732) being imported before the chain head is updated from the first imported segment (2731). This leads to extending the chain by two blocks (2731:2732) in one step, and the statediff code only receives a single event related to the chain head update, not at block 2732.This gap will not be caught by the gap filling code unless the process is restarted, since that code currently only runs once at startup.
This would be caught and corrected eventually if we set that code to run at an interval instead, but it is probably better to detect this condition as it happens--we have all the information we need to do so--and trigger statediffing of the intervening blocks.