🤖 [claude] Firehose finality: read the parent's Parlia snapshot (resolver never engaged in fh3.1-2) - #6
Merged
Johnaverse merged 1 commit intoSep 9, 2026
Conversation
…r engaged) The first canary showed every one-block with LIB = block - 200: the resolver keyed the Parlia snapshot on the block's own hash, but the tracer starts before consensus validates the header, which is when that snapshot is created, so it always found None. Key on the parent instead (new parent_hash argument in bnb-reth bnb-bf76323c-fh3.1-3): the parent's attestation source is complete by then, identical on every node, on the block's ancestry, and one block staler (head-3 steady state). Debug-log the None paths under target bsc::firehose. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YHvxpuVpZfzefJgwgqjAzn
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.
Summary
Follow-up to #5. On the first canary (
bsc-sfdm822, writing production one-blocks) 33/33 one-blocks carried LIB =block − 200: the resolver always returnedNone. Cause: the Firehose tracer starts before consensus validates the block's header, which is when the block's own Parlia snapshot is created, sosnapshot(hash)did not exist yet. The safe fallback worked as designed (no wrong LIB possible), but the deterministic finality never engaged.pinax-network/bnb-rethtagbnb-bf76323c-fh3.1-3:finalized_for_blocknow receivesparent_hashtoo (engine call sites and ExEx runner passheader().parent_hash()).snapshot(parent_hash).vote_data.source— complete at tracer start, identical on every node, on the block's own ancestry. LIB is one block staler than before (head−3 steady state), which is the conservative direction.Nonepaths are debug-logged underbsc::firehose.fh3.1-3; CHANGELOGdev-049d306-fh3.1-3.Test plan
dev-049d306-fh3.1-3, bumpeosn-sf-bsc4-test, deploy onbsc-sfdm822:x822one-block LIB distance becomes a constant 3 (not 200), monotonic, and equal for identical blocks across readers once others run it🤖 Created by Claude Code Fable 5.1 (effort: high)
🤖 Generated with Claude Code
https://claude.ai/code/session_01YHvxpuVpZfzefJgwgqjAzn