Checking a Bitcoin indexer's saved block after a reorg
An indexer resumes from height 850,000 after an outage. Comparing the hash saved at that height with the node's current answer reveals whether its checkpoint still belongs to the active chain.
Compare the checkpoint on the same network
Use a synchronised mainnet node for this mainnet example. Set SAVED_HASH to the hash stored by the indexer at height 850000. Confirm the network and local height before comparing hashes.
bitcoin-cli getblockchaininfo | jq '{chain, blocks}'
bitcoin-cli getblockhash 850000
bitcoin-cli getblockheader "$SAVED_HASH" | jq '{height, hash, confirmations}'
If the active hash differs and the saved header has confirmations equal to -1, this node knows the old header outside its active chain. A node that never learned the displaced branch may return an unknown-header error instead. Keep the original checkpoint for investigation and compare earlier stored heights to locate a common ancestor.
Resume ingestion from the shared ancestor
For example, if height 849998 matches and both subsequent saved blocks differ, roll back the effects of the two displaced blocks. Replay active blocks from 849999, checking each new block's previousblockhash against the last committed hash. Commit the derived records and their checkpoint together so a process restart can resume from a consistent position.
getchaintips adds context by listing branches the node knows. Its branchlen describes the branch associated with a reported tip. Calculate the indexer's rollback depth from its own stored hashes, since it may have stopped partway along that branch.
bitcoincore.org getblockheader · bitcoincore.org getchaintips