#35071 Reindex: save progress to continue after interruption

• Save reindex progress on interruption so restarts resume from the last block file
• Avoids re-reading earlier block files and re-populating orphan maps after an interrupted reindex

This pull request records reindex progress to the block tree database upon user interruption. It saves the last completed block file index and serializes the in-memory orphan block map so that subsequent node startups can resume reindexing from that file rather than re-scanning earlier files.

Problem: When a node operator interrupts a reindex, restarting the node re-scans all block files starting from blk00000.dat. Even though previously accepted blocks are skipped, re-reading the files and re-populating orphan maps creates perceived redundant work.

P4 · speedup

• P4 because the performance optimization is speculative and weakly justified
• Master already skips block validation on restart leaving only quick sequential file reads
• Persisting orphan maps in the block database adds complexity for marginal gains in an edge case

P4 because the optimization is speculative and weakly justified. On current master, restarting after an interruption without the -reindex parameter already skips block validation because blocks are already recorded in the block index, leaving only the sequential read overhead of the block files. Persisting checkpoint progress and serializing orphan multimaps to the block database adds code complexity for an edge case that already completes quickly.

Membership: Changes BlockTreeDB and ImportBlocks in src/node/blockstorage to manage block file scanning and reindex persistence.

Factors: security/stability 0, bug 0, performance 1, user value 1, leverage 0

• Author moved PR to draft to gather benchmarks and has been silent for 132 days

The author converted the PR to draft after acknowledging reviewers' point that block acceptance is already skipped, promising benchmarks, and has been inactive for 132 days.

Author status: silent since 2026-05-08 after moving the PR to draft to gather benchmarks

Open concerns:

• Reviewers noted that on master, restarting without -reindex already skips AcceptBlock for indexed blocks, making the scan very fast.
• Doubts about whether persisting orphan block maps into LevelDB adds unnecessary database complexity for negligible performance gains.

Resolved concerns:

• Flushing reindex progress on every single block file was replaced with saving only upon shutdown interrupt to avoid slowing normal reindexing.

• Reviewers doubted whether re-reading block files without re-validation is meaningfully slow
• Pointed out master already skips validation on restart so scanning is very fast (mzumsande)
• Asked for flame graphs or benchmarks demonstrating substantial restart overhead (maflcko)
• Author moved PR to draft to measure real overhead but has not returned

Mild: reviewers questioned whether re-scanning files without re-validating is actually slow; author moved to draft to benchmark and went silent.

Reviewers (maflcko, mzumsande) pointed out that re-reading block files on an interrupted reindex already avoids full validation on master, questioning the need for persisting orphan state in LevelDB. The author acknowledged this and agreed to test whether overhead exists, but has not returned.

• maflcko asked for flame graphs or benchmarks demonstrating that interrupted restarts have substantial overhead
• mzumsande pointed out that restarting without -reindex does not re-index from scratch and that file scanning is very fast
• pinheadmz admitted they had not realized master already skips block acceptance, and put the PR in draft to measure real overhead

Review verdicts (DrahtBot): 0

62 lines under test/bench/ci.

• src/node/blockstorage.cpp +63/-3
• test/functional/feature_reindex.py +59/-3
• src/node/blockstorage.h +6/-0

PR 35071 checkpoints the last processed block file and serializes orphan block positions to LevelDB when reindexing is interrupted, allowing the node to resume from that file rather than scanning from blk00000.dat. It addresses the perception that interrupting a multi-hour reindex forces the operator to redo all previous progress. However, reviewers pointed out that master already skips block validation on restart and scans existing files quickly, so the actual performance improvement remains unproven. The PR is in draft and has been stale for 132 days awaiting benchmarks from the author.