fix: view slot details regardless of current identity#355
Open
theobolo wants to merge 1 commit into
Open
Conversation
The slot details page gated validity on the current identity's leader slots, so a slot showed "belongs to another validator" whenever it wasn't led by the current identity. This hid slots the node actually produced under a previous identity — e.g. after an unstake, where the server also recomputes the slot's `mine` flag against the new identity and so can't be relied on to recognize them. Changes: - Gate slot detail validity on data availability: query the requested slot's publish even before it's considered valid (resolving the chicken-and-egg where a slot was only valid once fetched, but only fetched once valid), and treat any slot the server has a response for as viewable. The header still resolves the original leader from the epoch schedule. - Render the detailed view as soon as any detailed field is present (each subsection already hides itself when its data is missing) rather than gating the whole page on `limits`; show a clear "not available" message instead of a perpetual spinner — in DetailedSlotStats and in the Compute/Banks cards — when the server no longer retains a slot's per-transaction data. - Make the Earliest/Most Recent quick-search reflect the slots THIS node produced, identified by the server-stamped `mine` flag (unioned from the cached responses and the mine rankings), instead of the current identity's leader schedule. The schedule lists every slot of an identity even after it moves to another node, so post-unstake it would wrongly surface slots produced elsewhere; the mine flag does not.
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.
Summary
Fix slot details visibility for slots produced by this node under a previous identity, and improve handling of unavailable historical per-transaction data.
Context
The slot details page previously gated validity on the current identity's leader slots. As a result, any slot not led by the current identity was shown as belonging to another validator.
This caused an issue after identity changes, for example after an unstake: slots actually produced by this node under a previous identity were hidden, because the server also recomputes the slot's
mineflag against the new identity and therefore cannot always be used to recognize older slots correctly.Changes
Slot details validity
This resolves the previous chicken-and-egg issue where a slot was only considered valid once fetched, but was only fetched once considered valid.
Detailed view rendering
not availablemessage instead of a perpetual spinner when historical per-transaction data is no longer retained.This applies to:
DetailedSlotStatsQuick-search behavior
Update the Earliest / Most Recent quick-search logic so it reflects slots produced by this node, instead of slots from the current identity's leader schedule.
Produced slots are now identified using the server-stamped
mineflag, unioned from:This is more accurate after an identity move or unstake. The leader schedule lists every slot for an identity even after it moves to another node, which can incorrectly surface slots produced elsewhere. The server-stamped
mineflag is a better signal for what this node actually produced.Review notes
Parts of this change were AI-assisted.
The non-obvious areas worth reviewing carefully are:
mineProcessedSlotsAtominsrc/atoms.tsmineflag.getSlotStateinsrc/features/Overview/SlotPerformance/atoms.tsValidation
Verified live against a Firedancer
v0.911validator.