Repository navigation
fix: the tries-rebuilt event says what happened, under the node's prefix - #116
Merged
Merged
Conversation
rssh
changed the title
… they were before After a successful rebuild the event appended the pre-rebuild mismatch bare — "tries rebuilt … at treasury head H: spi root X != the chain's Y" — which reads as the rebuild's outcome, so an operator seeing it in Discord would think the repair had failed when the startup checks that follow pass. The line now states the result first, with the rebuilt cpo and spi roots that reconstruct_both has already held against the singleton, and labels the old mismatch "Before the rebuild". The operator guide's example shows the real lines.
…nd the runtime event carries the node's prefix Once the rebuilt pair is on disk and matches the singleton, a failure to remove pending-tm.json no longer turns the repair into an Err: at startup that logged "rebuild FAILED" over tries step 10 then passed, and at runtime it stopped the batch on TriesBehind with its tries in sync. The unlink can only fail on a state directory already in trouble (immutable file, a directory in its place, a filesystem remounted read-only after an I/O error), and a leftover record is harmless because a fold writes nothing unless it reproduces the roots its movement committed, so the rebuild now says the record stays instead. The event line moves from the repairer to its two callers through a shared Repaired::describe, so the runtime one is written under the node's usual [epoch=…] prefix with the batch, and a startup rebuild is one line instead of two.
rssh
force-pushed
the
fix/tries-rebuilt-wording
branch
from
September 25, 2026 11:51
db749b5 to
18a79fb
Compare
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
1 participant
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.
Three things about how a tries rebuild is reported.
The line said the opposite of what happened. After a successful rebuild the event appended the pre-rebuild mismatch unlabelled —
tries rebuilt … at treasury head 26b974ec…:0: spi root 49bbf9f9… != the chain's 8216f9dd…— which on the roster box after today's upgrade read as a failed rebuild while check 10/11 passed. It now leads with the result and the rebuilt roots (already held against the singleton byreconstruct_both) and labels the old stateBefore the rebuild:.A rebuild could be reported FAILED after it succeeded.
PendingTm::clearran afterinstall_pairand its error failed the whole repair: at startup that loggedrebuild FAILEDover tries step 10 then passed, and at runtime the batch stopped onTriesBehindwith its tries in sync. The unlink can only fail on a state directory already in trouble (immutable file, a directory in its place, a filesystem remounted read-only after an I/O error). A leftover record is harmless — a fold writes nothing unless it reproduces the roots its movement committed — so the repair now succeeds and the line says the record stays.The runtime event had no prefix. The event moves from
ChainTriesRepairerto its two callers via a sharedRepaired::describe. At runtime it is anepoch_event_warn!under the node's usual[epoch=…]prefix, with the batch; at startup (no identity or epoch yet) the rebuilt line and the "losing its state directory" hint are one line instead of two. The event-inventory tripwire goes from 6 to 7 failure events, with the reason recorded: this one has no success twin.docs/operator-guide.mdshows the new lines and says the example is wrapped and shortened.