-
Notifications
You must be signed in to change notification settings - Fork 126
Followup pre populate chain validity window #2012
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
* Add NewPopulatedTimeValidityWindow for direct initialization * Simplify validity window population with consistent timestamp comparison * Improve VM initialization flow to handle validity window during restart * Unify calculateOldestAllowed function implementation * Update component initialization order to break circular dependencies
hypersdk/internal/validitywindow/syncer.go Line 138 in 5d39841
Line 83 in 5d39841
Line 727 in 5d39841
Line 718 in 5d39841
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we define a function within startNormalOp
(always called before transitioning to normal operation) that will return an error if the validity window does not report as fully populated yet?
// AddNormalOpStarter registers a callback that will be executed when the engine invokes SetState(snow.NormalOp) | ||
// i.e., transitioning from state sync / bootstrapping to normal operation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: these will also be called on SetState(snow.NormalOp)
when still performing dynamic state sync.
We could try and make that explicitly handled here so that the snow package can support callbacks for actually entering normal operation (ie. exclude dynamic state sync).
…-populate-chain-validity-window
…p safety checks enhance VW implementation with a populated flag that tracks whether a complete validity window has been observed. Reducing API surface area
…uring consistent view of state across the network
log: log, | ||
tracer: tracer, | ||
chainIndex: chainIndex, | ||
seen: emap.NewEMap[T](), | ||
getTimeValidityWindow: getTimeValidityWindowF, | ||
populated: false, | ||
} | ||
if lastAcceptedBlock != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allowing nil
lastAcceptedBlock
for testing purposes. While not ideal for production use, passing nil
signals the creation of an empty validity window. The constructor handles this case gracefully. I'm open to improvements.
vw := NewTimeValidityWindow(ctx, log, tracer, chainIndex, nil, ...)
…`startNormalOp` ensuring both paths leading to normal operation require populated validity window
This PR addresses several issues related to the validity window initialization flow.
Improved Validity Window API:
NewPopulatedTimeValidityWindow
as a factory method to create and populate a validity window in one steppopulateValidityWindow
private (formerlyPopulateValidityWindow
) to reduce API surface areapopulateValidityWindow
Cleaner VM Initialization Flow:
Validity Window Initialization