Make omnichain indexing status builder to correctly recognize all queued chains #1821
Description
Currently, running ENSIndexer with the following test configuration:
PLUGINS=subgraph,lineanames,registrars DATABASE_SCHEMA=t10 NAMESPACE=mainnet pnpm -F ensindexer start --root ./ponder
results in producing an Indexing Status object that describes reality incorrectly.
The reality is that ENSIndexer starts the backfill for the Mainnet chain (chain ID 1), while the remaining chains remain queued for indexing.
However, the Indexing Status object presents all chains as being in the backfill status, which is incorrect.
Incorrect Indexing Status object
The consequence of the incorrect Indexing Status object is that some invariants are failing and preventing the ENSDb Writer Worker from updating the relevant Indexing Status record in ENSDb. The error says:
[EnsDbWriterWorker]: Error retrieving or validating Indexing Status Snapshot: Error: Invalid OmnichainIndexingStatusSnapshot:
✖ `omnichainIndexingCursor` must be lower than the earliest start block across all queued chains.
Root cause analysis
The Base mainnet chain (chain ID 8453) and the Linea mainnet chain (chain ID 59144) both define config.startBlock way ahead the latestIndexedBlock for the Mainnet (chain ID 1). Given the omnichain indexing strategy, both, Base mainnet chain and Linea mainnet chain should remain in queued state until the latestIndexedBlock for Ethereum mainnet reaches their respective config.startBlock. That does not happen, and both of those chanis are seen as in the backfill status.
The core issue here is how latestIndexedBlock for each of those chains is just a several blocks ahead their respective config.startBlock. Because of that, these chains are not considered queued. For a chain to be considered in queued state, its config.startBlock must be same as its latestIndexedBlock.
Perhaps this is some internal Ponder feature/bug. Perhaps the initial events to be indexed are not found in the config.startBlock, but on the latestIndexedBlock.