refactor(vmsync): extract SyncStrategy pattern for static state sync
#4652
+305
−219
Conversation
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
Restructure the vmsync package to separate concerns and prepare for future dynamic state sync support. - Extract `finalizer.go` - VM state finalization logic (`finishSync`, `commitMarkers`) moved to dedicated `finalizer` struct. - Add `SyncStrategy` interface with `Start` method for sync execution. - Implement `staticStrategy` for current sequential sync behavior. - Simplify `client.go` to orchestrate sync lifecycle via strategy. This refactoring enables adding dynamic state sync as a separate strategy implementation without modifying existing static sync logic. resolves #4651 Signed-off-by: Tsvetan Dimitrov ([email protected])
powerslider
changed the title
SyncStrategy pattern for static state sync
alarso16
reviewed
Dec 5, 2025
| GetEthBlock() *types.Block | ||
| // SyncStrategy defines how state sync is executed. | ||
| // Implementations handle the sync lifecycle differently based on sync mode. | ||
| type SyncStrategy interface { |
Contributor
There was a problem hiding this comment.
The name SyncStrategy indicates to me that this interface has something to do with a strategy, which is just not true. It just syncs. Additionally, the name Start indicates that it only starts the syncers, and then returns. Your comments are correct and the code works here, I just don't like the names
May I suggest SyncOperation and Sync? I honestly don't eve know if this needs to be a whole interface (does it?) You could also just define:
type SyncOperation func(context.Context, message.Syncable) error
| } | ||
|
|
||
| // newFinalizer creates a new finalizer with the given dependencies. | ||
| func newFinalizer( |
Contributor
There was a problem hiding this comment.
Is this creator going to have more work to do? I'm not sure abstracting this into a struct is productive
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.
Why this should be merged
Check #4651
How this works
Restructure the
vmsyncpackage to separate concerns and prepare for future dynamic state sync support.finalizer.go- VM state finalization logic (finishSync,commitMarkers) moved to dedicatedfinalizerstruct.SyncStrategyinterface withStartmethod for sync execution.staticStrategyfor current sequential sync behavior.client.goto orchestrate sync lifecycle via strategy.This refactoring enables adding dynamic state sync as a separate strategy implementation without modifying existing static sync logic.
How this was tested
existing UT
Need to be documented in RELEASES.md?
no
resolves #4651
Signed-off-by: Tsvetan Dimitrov ([email protected])