#35071 Reindex: save progress to continue after interruption
| Reviewability | Reviews | Agreement | Size | ||||
|---|---|---|---|---|---|---|---|
| #35071 Reindex: save progress to continue after interruption | Author silent 177d | 0 | Mild | 69 + 59 tests | |||
|
|
|
|
| |||
Reviewability: ReadyStalePaused Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs. Size: lines added or modified outside tests, then in tests; greener = smaller. | |||||||
Goal
Save reindexing progress upon interruption so that a restarted node resumes from the last completed block file instead of restarting from blk00000.dat. The last completed block file number and the in-memory orphan block positions are persisted to the block tree database when an interrupt is signaled. Once all block files are processed, the reindex flag and progress checkpoints are erased in an atomic, synced database write.
Problem: When a node reindex is interrupted by shutdown or a crash, or if interrupted during chain activation before reindex completion is flushed, the next startup restarts the reindex from the very first block file (blk00000.dat), discarding hours or days of indexing work.
Evidence of importance:
- PR description: 'Currently, if the reindex process is interrupted it will start over on next run at blk00000.dat. Even after reindexing is finished when the node is in ActivateBestChain() an interruption may STILL require a full reindex process because DB_REINDEX_FLAG is written false, but not flushed.'
Scope: Touches blockstorage database schema with two new key types for reindex checkpointing and adds a functional test case to feature_reindex.py.
Reviewability
Stale · Author silent 177d
No author activity for 177 days; a review may wait a long time for a response.
Agreement
Mild
objection that needs a change was answered, no reply from the objector (maflcko: persisting orphan block maps and reindex state adds database complexity without evidence of meaningful overhead or perfo)
Thread notes: Initial read of PR 35071. Early concerns about slowing happy-path reindexing by writing after every file were resolved by pushing a change to only save on interrupt, but reviewers noted master already skips re-indexing when restarting without -reindex, prompting the author to put the PR into draft to measure actual overhead.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| maflcko (member) | objection, approach | writing reindex progress to LevelDB after every block file slows down the reindex happy path for an edge case | fixed · fix pushed · v1, not yet re-checked | answered | yes | 2026-04-14: 'Not sure about slowing down the happy path for an edge case' Status from: 2026-05-07: pinheadmz: 'Changed behavior to only save progress on interrupt instead of after every file (so happy path remains unaffected)' |
| mzumsande (member) | objection, scope | supporting unclean restarts during reindexing adds unnecessary complexity for a rare edge case | fixed · fix pushed · v1, not yet re-checked | answered | yes | 2026-04-15: 'accommodating unclean restarts during reindex seems too much of a special case.' Status from: 2026-05-07: pinheadmz: 'Changed behavior to only save progress on interrupt instead of after every file' |
| maflcko (member) | objection, usefulness | persisting orphan block maps and reindex state adds database complexity without evidence of meaningful overhead or performance improvement on restart | answered · reply on record; standing not assessed yet · v1, not yet re-checked | changed | yes | 2026-05-08: 'Without seeing that this improves anything for anyone (with performance numbers or graphs), then I don't see the point.' |
| mzumsande (member) | objection, usefulness | the change may be unnecessary because restarting without -reindex on master already skips AcceptBlock and quickly resumes from disk | answered · reply on record; standing not assessed yet · v1, not yet re-checked | answered | yes | 2026-05-08: 'As long as you drop the `-reindex` parameter in the restart run it won't start indexing from scratch again after a interrupt (on master).' |
Participants:
- maflcko (member, objection, 6 statements 2026-04-14 to 2026-05-08): questioned restart overhead, asked for flame graphs/benchmarks, and challenged the usefulness of persisting state without proven benefit
- mzumsande (member, objection, 2 statements 2026-04-15 to 2026-05-08): objected to accommodating unclean restarts and pointed out that master already skips block re-indexing when restarting without -reindex
Files
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
Card
The short text the ranking pass compares across PRs.
Allows interrupted reindex operations to resume from the last completed block file rather than restarting from the beginning. When an interrupt is detected during reindexing, the node persists the last completed block file index along with the serialized orphan block map to the block tree database, and atomically clears all reindex state with a synced write once complete. This avoids discarding hours or days of reindexing work if a node is stopped or interrupted before completion.
Data
thread read through 2026-05-08 (15 statements), head 99d0d61cab
Discussion read under schema 1 rules: suggestions and questions may be missing, and an objection may combine several harms (schema history).
labels: none · draft
Categories
Validation
P3 · new feature
Resuming an interrupted reindex avoids repeating work across processed block files. However, reviewers note that existing behavior already avoids re-processing existing blocks on restart, making this an incremental quality-of-life improvement rather than an urgent correctness or performance fix.
Membership: Modifies src/node/blockstorage.cpp and block tree database schema to persist reindex checkpoint state across interruptions.
Factors: security/stability 0, bug 0, performance 1, user value 1, leverage 0