Summary
The start_block field in each chain's configuration is fully wired for input (YAML tag + validation) but is never read anywhere in the indexing logic. It's effectively dead configuration: operators can set it expecting to control where indexing begins, but it has no effect.
Details
The field is defined in pkg/common/config/types.go:
StartBlock int `yaml:"start_block" validate:"min=0"`
It is parsed from YAML and validated (min=0), but a codebase-wide search finds no reads of the field.
The only reference to config.StartBlock outside the struct definition is a comment in pkg/store/blockstore/store.go:
// propagate, so callers never silently rewind to config.StartBlock.
The actual starting block is determined by RegularWorker.determineStartingBlock() in internal/worker/regular.go, which uses only two sources:
- The KV store's last indexed block (resume from previous progress).
- The current chain head on cold start (or when the store is unavailable), via
waitForChainHead().
The configured start_block is never consulted as the initial anchor.
As a result, on a cold start the indexer begins at the current chain head rather than the configured start_block.
Why this is misleading
The example configuration (configs/config.example.yaml) presents start_block as a meaningful per-chain option, for example:
One entry is even annotated as a checkpoint sequence, which strongly implies that indexing will begin from that block.
In practice, the value is ignored without any warning or error. Operators expecting to backfill historical data from a specific block will instead begin indexing from the current chain head.
Expected behavior
One of the following should be implemented:
- Option A: Honor
start_block during cold starts (when no KV state exists) by using it as the initial starting block in determineStartingBlock().
- Option B: Remove the unused
start_block field from the configuration struct and the example configuration to avoid misleading operators.
Environment
Relevant files
pkg/common/config/types.go:52internal/worker/regular.go:195pkg/store/blockstore/store.go:105
Summary
The
start_blockfield in each chain's configuration is fully wired for input (YAML tag + validation) but is never read anywhere in the indexing logic. It's effectively dead configuration: operators can set it expecting to control where indexing begins, but it has no effect.Details
The field is defined in
pkg/common/config/types.go:It is parsed from YAML and validated (
min=0), but a codebase-wide search finds no reads of the field.The only reference to
config.StartBlockoutside the struct definition is a comment inpkg/store/blockstore/store.go:// propagate, so callers never silently rewind to config.StartBlock.The actual starting block is determined by
RegularWorker.determineStartingBlock()ininternal/worker/regular.go, which uses only two sources:waitForChainHead().The configured
start_blockis never consulted as the initial anchor.As a result, on a cold start the indexer begins at the current chain head rather than the configured
start_block.Why this is misleading
The example configuration (
configs/config.example.yaml) presentsstart_blockas a meaningful per-chain option, for example:One entry is even annotated as a checkpoint sequence, which strongly implies that indexing will begin from that block.
In practice, the value is ignored without any warning or error. Operators expecting to backfill historical data from a specific block will instead begin indexing from the current chain head.
Expected behavior
One of the following should be implemented:
start_blockduring cold starts (when no KV state exists) by using it as the initial starting block indetermineStartingBlock().start_blockfield from the configuration struct and the example configuration to avoid misleading operators.Environment
mainRelevant files
pkg/common/config/types.go:52internal/worker/regular.go:195pkg/store/blockstore/store.go:105