Repository navigation
health: count the orphan rate per height, not per candidate row - #109
Merged
Merged
Conversation
A template stuck on an old tip keeps miners solving the same height, and each solve is its own rejected row. On vaultnet one wedged-enforcer incident (2026-10-29) left six rejected rows at 974,037; every block since confirmed, yet the check read "4 of the last 10" and stayed red, and would have until two more blocks landed. Group by height: a height is reached if any candidate there confirmed, lost if all were orphaned or rejected. A pool losing blocks at many heights still fails as before (new test). vaultnet now reads 4 of 5. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
orphan_ratecounted eachblocks_foundrow. When a template is stuck on an old tip, miners keep solving the same height, and every solve becomes its own rejected row. On pool.vaultnet.sh, one incident on 2026-10-29 (the enforcer got stuck in a mempool re-sync, so the template stayed on 974,037 for about 11h) produced six rejected rows. Every block after the fix confirmed, but the dashboard still showed "only 4 of the last 10 candidates reached the chain". It would have stayed red until two more blocks were found.Change
Count heights instead of rows. A height counts as reached if any candidate at it confirmed, and as lost if every candidate there was orphaned or rejected. The window is still the last 100, now 100 heights.
Tests
node --test test/*.test.js: 207 pass, 0 fail.Run read-only against vaultnet's live DB, the new query gives good=4, lost=1 (80%).
🤖 Generated with Claude Code