Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rare chance of initial pruning proof building issues #444

Closed
coderofstuff opened this issue Mar 28, 2024 · 0 comments
Closed

Rare chance of initial pruning proof building issues #444

coderofstuff opened this issue Mar 28, 2024 · 0 comments
Labels
bug Something isn't working high-priority

Comments

@coderofstuff
Copy link
Collaborator

coderofstuff commented Mar 28, 2024

Describe the bug

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

  1. Run an initial sync.
  2. 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)

@coderofstuff coderofstuff added bug Something isn't working high-priority labels Mar 28, 2024
michaelsutton added a commit that referenced this issue Apr 10, 2024
* add a strict assertion which should catch the pruning bug before actual data is pruned

* possible fix: add `block_at_depth_2m` as an additional traversal root

* rollback: rollback the previous fix since it's not the root cause

* add additional dbg info to assertion

* bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node)

* enable mainnet mining by default

* simplify kip 9 beta condition + more mass tests

* set default tracked addresses to 1M

* fix tracker prealloc property + adds compile time assertion for upper bound
@github-project-automation github-project-automation bot moved this to ✅ Done in Rust rewrite Apr 11, 2024
smartgoo pushed a commit to smartgoo/rusty-kaspa that referenced this issue Jun 18, 2024
…t#449)

* add a strict assertion which should catch the pruning bug before actual data is pruned

* possible fix: add `block_at_depth_2m` as an additional traversal root

* rollback: rollback the previous fix since it's not the root cause

* add additional dbg info to assertion

* bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node)

* enable mainnet mining by default

* simplify kip 9 beta condition + more mass tests

* set default tracked addresses to 1M

* fix tracker prealloc property + adds compile time assertion for upper bound
D-Stacks pushed a commit to D-Stacks/rusty-kaspa that referenced this issue Jul 12, 2024
…t#449)

* add a strict assertion which should catch the pruning bug before actual data is pruned

* possible fix: add `block_at_depth_2m` as an additional traversal root

* rollback: rollback the previous fix since it's not the root cause

* add additional dbg info to assertion

* bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node)

* enable mainnet mining by default

* simplify kip 9 beta condition + more mass tests

* set default tracked addresses to 1M

* fix tracker prealloc property + adds compile time assertion for upper bound
D-Stacks pushed a commit to D-Stacks/rusty-kaspa that referenced this issue Jul 12, 2024
…t#449)

* add a strict assertion which should catch the pruning bug before actual data is pruned

* possible fix: add `block_at_depth_2m` as an additional traversal root

* rollback: rollback the previous fix since it's not the root cause

* add additional dbg info to assertion

* bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node)

* enable mainnet mining by default

* simplify kip 9 beta condition + more mass tests

* set default tracked addresses to 1M

* fix tracker prealloc property + adds compile time assertion for upper bound
D-Stacks pushed a commit to D-Stacks/rusty-kaspa that referenced this issue Jul 17, 2024
…t#449)

* add a strict assertion which should catch the pruning bug before actual data is pruned

* possible fix: add `block_at_depth_2m` as an additional traversal root

* rollback: rollback the previous fix since it's not the root cause

* add additional dbg info to assertion

* bug fix: write level relations for trusted blocks (blocks in the pruning point anticone of a newly synced node)

* enable mainnet mining by default

* simplify kip 9 beta condition + more mass tests

* set default tracked addresses to 1M

* fix tracker prealloc property + adds compile time assertion for upper bound
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working high-priority
Projects
Status: Done
Development

No branches or pull requests

1 participant