fix(web): flag serving checkpoint by block root, not epoch#243
Open
barnabasbusa wants to merge 1 commit intomasterfrom
Open
fix(web): flag serving checkpoint by block root, not epoch#243barnabasbusa wants to merge 1 commit intomasterfrom
barnabasbusa wants to merge 1 commit intomasterfrom
Conversation
The historical-checkpoints table flags the row currently being served by the checkpointz instance. It did this by comparing each row's epoch against `status.data.finality.finalized.epoch`. Two issues: 1. The slots list is built from `d.head` (majority-decided finality), but the status's `finality.finalized` is `d.servingBundle` (the last fully-downloaded bundle). When bundle downloads lag — e.g. after an upstream blip or on short-lived devnets — `d.head` advances while `d.servingBundle` stays behind, so the slots list contains rows for epochs that don't yet have a serving bundle. The flag then either appears on a non-top row with no explanation or disappears entirely until the bundle catches up. 2. Epoch-only comparison is ambiguous in principle (two different roots can share the same finalized epoch across restarts / reorgs, however rare post-finality). Matching by block root is the semantically correct signal: "which row's bundle is the one we're serving". Prefer matching by `slot.block_root === status.finality.finalized.root` and fall back to the old epoch-based comparison for rows whose block_root hasn't been populated yet.
3 tasks
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
The historical-checkpoints table flags the row currently being served. Previously it matched by epoch (
status.data.finality.finalized.epoch === slot.epoch), which has two problems:d.head(majority-decided finality) whilestatus.data.finalitycomes fromd.servingBundle(last fully-downloaded bundle). When bundle downloads lag — e.g. short-lived devnets, kurtosis enclaves, or any transient fetch failure —d.headadvances whiled.servingBundlestays behind. Result: the slots list contains rows for epochs that aren't yet serving, so the flag appears on a non-top row or disappears until the bundle catches up.Switch to
slot.block_root === status.finality.finalized.root, with a fallback to the old epoch comparison for rows whoseblock_roothasn't been populated yet.Repro
Spin up a kurtosis devnet with
SLOTS_PER_EPOCH=8. While bundle downloads occasionally retry, the Checkpoints table's flag icon goes missing despite the upstream tab showing healthy finality.Test plan
npx tsc --noEmitcleannpm run lintcleanstatus.data.finality.finalized.root, even whend.headis ahead ofd.servingBundleRelated: #241 (underflow fix for
ListFinalizedSlotsthat exposes this UI bug on short-lived chains).