There is a very rare chance that the initial pruning proof sync is somehow corrupted. Example logs:
2024-03-28 18:13: 2024-03-28 18:13:23.283+01:00 [INFO ] Accepted block cbd53132098e712199b33968b34878edc09661baa9b1412ac1832c580693bd1b via relay
2024-03-28 18:13: thread 'pruning-processor' panicked at consensus/src/processes/pruning_proof/mod.rs:650:22:
2024-03-28 18:13: called Result::unwrap() on an Err value: "level: 32, err: block at depth error: high: 99fb3fdc4eb83defa53ffe908e58746875ba5a81d6b94fd082aa5db3c94d6945, depth: 2000, current: d07727509d0e36ec06ebff8fa843e92ab11f03e66b88cd6cedb1e32697ac397f, high blue score: 1801, current blue score: 793, key GhostdagCompact/32/935e0a789ea348d0d0d5edffaf2af58704260ac6e4105cb5aa58bb431bbf8698 not found in store"
2024-03-28 18:13: note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
2024-03-28 18:13: Exiting...
2024-03-28 18:13: 2024-03-28 18:13:23.717+01:00 [INFO ] kaspad v0.13.4
To Reproduce
Run an initial sync.
Most of the times this will not occur, but sometimes it will
Expected behavior
The initial sync and building of pruning proof never fails
Desktop (please complete the following information):
Kaspad version: 0.13.4
Additional context
This is a MUST FIX bug for adoption of the rust node. The final release must contain the fix for this.
When this is encountered, the only recourse is to delete the datadir and do a resync. Either delete the datadir manually or run kaspad with --reset-db (once)
Describe the bug
There is a very rare chance that the initial pruning proof sync is somehow corrupted. Example logs:
To Reproduce
Expected behavior The initial sync and building of pruning proof never fails
Desktop (please complete the following information):
Additional context This is a MUST FIX bug for adoption of the rust node. The final release must contain the fix for this.
When this is encountered, the only recourse is to delete the datadir and do a resync. Either delete the datadir manually or run kaspad with
--reset-db(once)