chore(sync/types): add sync/types package (syncer contract types) #4405
Conversation
…er interface resolves #4404 Signed-off-by: Tsvetan Dimitrov ([email protected])
powerslider
changed the title
| @@ -0,0 +1,22 @@ | |||
| // Copyright (C) 2019-2025, Ava Labs, Inc. All rights reserved. | |||
There was a problem hiding this comment.
vms/evm/sync/types/types.go
This is in the correct folder? what other types will be in sync/types?
There was a problem hiding this comment.
Here is the original code. Probably I'll add only SummaryProvider in a later PR when I move the code that will use it. Only the Extender interface will not be migrated for now, because we will not migrate the atomic syncer (which uses it).
| // Copyright (C) 2019-2025, Ava Labs, Inc. All rights reserved. | ||
| // See the file LICENSE for licensing terms. | ||
|
|
||
| package types |
There was a problem hiding this comment.
It's not clear to me why this package exists - it doesn't have the same name, but it feels like an "interfaces" package which is an anti-pattern. This is only used in coreth's vmsync package for the common syncer types defined in sync/statesync. Would it make sense to move to one of those two packages? Go typically defines interfaces in the consumer but if there's a well-agreed upon abstraction and multiple packages are using it as an interface can be reasonable to define it in the producer.
On an unrelated note... why is vmsync called vmsync? It seems like we named it that way to disambiguate against sync, but you can use import aliasing to get around this when there is a conflict.
| // Name returns a human-readable name for this syncer implementation. | ||
| Name() string | ||
|
|
||
| // ID returns a stable, machine-oriented identifier (e.g., "state_block_sync", "state_code_sync", | ||
| // "state_evm_state_sync", "state_atomic_sync"). Implementations should ensure this is unique and | ||
| // stable across renames for logging/metrics/deduplication. | ||
| ID() string |
There was a problem hiding this comment.
The caller here already knows about the concrete syncer types being registered, so we don't need to make this part of the interface public contract. Even if we did, it feels like overkill that we're adding this to the interface for duplicate handling because we own the syncers that we're registering - so it shouldn't happen anyways. It also feels leaky that something that just knows about how to perform a sync operation also needs to define its own metrics namespace and it's own "human-readable name".
3 participants
Why this should be merged
Check #4404
How this works
Syncerinterface type that will be the main contract for all syncer implementations migrated in follow up PRs.How this was tested
existing UT
Need to be documented in RELEASES.md?
no
resolves #4404
Signed-off-by: Tsvetan Dimitrov ([email protected])