Problem: Loading a UTXO snapshot on a pruned node can leave the active tip without block or undo data. Attempting a rollback with dumptxoutset then triggers an assertion and terminates the node.
Fix: Reuse GetPruneHeight to reject rollback with the existing pruning error when the required data is unavailable.
Record the assertion when the snapshot tip lacks block data or undo, then restart the node to continue the existing checks.
Reuse GetPruneHeight to return the existing pruning error when the snapshot tip lacks block or undo data.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline and AI policy for information on the review process.
| Type | Reviewers |
|---|---|
| Concept ACK | musaHaruna |
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
Concept ACK. The fix looks straightforward and contained: GetPruneHeight handles missing data at the tip before calling GetFirstBlock, allowing the RPC to return an error instead of hitting the assertion.
I have a few questions about the surrounding behavior.
Should the early availability check also cover non-pruned nodes? They can load a snapshot without having the historical block or undo data. I understand that the code limits the early check to pruning mode, and non-pruned nodes can fail later during rollback. Could checking availability earlier avoid copying the UTXO set before discovering that rollback is impossible? Registering TemporaryPruneLock could still remain conditional on IsPruneMode().
Would a more general error message describe these cases better? Specifically, changing:
Could not roll back to requested height since necessary block data is already pruned.
to:
Could not roll back to requested height because required block or undo data is unavailable.
After loading a UTXO snapshot, the node may lack historical block or undo data because it has not obtained or generated it yet, not because pruning deleted it. Keeping the existing wording for this focused fix seems reasonable, though.
Could the boundary eventually compare the highest missing-data height against the target using > instead of >=? The loop in CreateRolledBackUTXOSnapshot uses: while (block_index->nHeight > target->nHeight)
For example, exporting state 299 from tip 301 disconnects blocks 301 and 300, so it does not need undo for block 299. If GetPruneHeight returns 299, the current 299 >= 299 check rejects that request, whereas 299 > 299 would allow it. Am I missing another requirement for the target’s data?
In a locally modified version using > and applying the early availability check to both pruned and non-pruned nodes, the added boundary tests passed. Exporting state 299 succeeded and matched the original snapshot’s UTXO hash, while exporting state 298 still failed.