mirror of
https://github.com/luxfi/indexer.git
synced 2026-09-24 00:25:37 +00:00
zeekayandHanzo Dev
fe9cf8d4f7
The zoo chain was relaunched and its index never followed. It is serving 24,607 blocks of a chain that no longer exists: at height 5000 the index holds 0xd798ca91 where the chain now has 0xa6c56d04, and its newest block is dated two days ago while the live chain sits at 9,564. indexNewBlocks resumes from MAX(number)+1 and loops while that is <= the head. A chain rebuilt from genesis reports a head far below everything already stored, so the resume point lands past it, the loop body never runs, and the cursor cannot move again. There is no recovery from this by waiting: the further the new chain gets, the longer it stays behind a cursor left on the old one. Deciding this on height alone would be wrong in the other direction. One backend of a load-balanced set lagging its peers reports the same shape as a relaunch, and erasing a chain because a node was slow is worse than being stale. So the height is only used to decide when to ask a question that has a real answer: block 0's hash. Every node knows which chain it is on however far behind it is, so a changed genesis means a different chain and an unchanged one settles it. The streak before the probe keeps the common case free of extra RPCs. Each chain is indexed into its own database, so forgetting one reaches nothing else. The hash is recorded on the first poll that can reach the chain, because a relaunch cannot be recognised without knowing what came before it, and an unreadable or unrecorded genesis is not evidence of anything, so both keep the index. The graph indexer has resolved this for its own cursor since v1.2.x. This gives the block indexer the same footing. Co-authored-by: Hanzo Dev <[email protected]>