-
Notifications
You must be signed in to change notification settings - Fork 709
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
Move syncing code from sc-network-common
to sc-network-sync
#1912
Conversation
sc-network-common
to sc-network-sync
sc-network-common
to sc-network-sync
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.
I don't think this should be silent. There are at least two external teams that are working on their own syncing implementations so this will likely affect them. At least the removal of ChainSync
is something that should be mentioned, with a note that there will be some kind of new ChainSync
trait in the near future.
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.
Looking good. Just a little bit confused why some types are being made public?
@@ -206,24 +206,65 @@ struct GapSync<B: BlockT> { | |||
|
|||
/// Action that [`engine::SyncingEngine`] should perform after reporting imported blocks with | |||
/// [`ChainSync::on_blocks_processed`]. | |||
enum BlockRequestAction<B: BlockT> { | |||
pub enum BlockRequestAction<B: BlockT> { |
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.
Why do we need to make this public?
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.
It's consumed by SyncingEngine
, that owns ChainSync
.
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.
But isn't this in the same crate?
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.
Technically, SyncingEngine
is in the same root module as ChainSync
, because ChainSync
is defined in lib.rs
. So pub
is not needed at all (even as pub(crate)
). Semantically, these types are public for SyncingEngine
, so I feel inclined to highlight this with either pub
or pub(crate)
.
pub(crate)
is probably a better option, but may be it's also worth moving ChainSync
to a separate chain_sync.rs
file.
@bkchr would it be better to move ChainSync
and its types to a separate file and use pub(crate)
for types consumed by SyncingEngine
?
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.
@bkchr would it be better to move
ChainSync
and its types to a separate file and use pub(crate) for types consumed by SyncingEngine?
Done. PR looks scary now due to moved code, but overall situation with ChainSync
should have improved.
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.
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.
pub(crate)
is probably a better option, but may be it's also worth movingChainSync
to a separatechain_sync.rs
file.
Yeah sorry for these dumb questions :P I should have realized that the module is private to the crate. Pub is fine by me here.
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.
Done
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.
I was thinking this reordering could've been done in another PR but whatever. SyncingEngine
should be moved to sync/src/lib.rs
but that can be done in another PR.
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.
Why SyncingEngine
should be moved to the root module and not kept in it's own module, may be reexporting it in the root module?
What is the status of completely getting rid off sync in the networking crate? Because ideally there should not exist a chain sync trait at all. |
There won't be |
Do we really need to make sync itself generic? I don't think so? As this is some self contained implementation. |
That is not the current plan at least. We are most likely going to introduce some traits for the strategies that we discussed earlier, simply to make the code easier to maintain and plug additional syncing implementations without major headache. |
Okay :) |
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.
Moving to its own file sounds reasonable!
} | ||
|
||
#[cfg(test)] | ||
mod test { |
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.
If you are at it, why not also move them into their own file?
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.
Done
Change introduced here: paritytech/polkadot-sdk#1912
* Get `entropy-shared` compiling with updated deps * Fix `entropy-shared` build for `wasm-no-std` * Make `pallet-staking-extension` compile Starts introducing some of the changes brought in by paritytech/polkadot-sdk#1484. * Introduce staking changes from paritytech/substrate#12970 * Add RuntimeFreezeReason from paritytech/polkadot-sdk#1900 * Re-map errors in staking extension pallet * Bump `pallet-programs` * Missed a crate dep for staking extension * Remove commented out code * Get `pallet-relayer` compiling * Fix relayer test compilation * Fix `pallet-free-tx`'s tests * Reorder config types * Bump `pallet-propagation` dependencies * Bump `pallet-slashing` dependencies * Bump `pallet-transaction-pause` This includes the deprecation of `Balances::transfer` from paritytech/polkadot-sdk#1226. * TaploFmt * Use `StakingAccount` instead of `.into()` * Import `vec` macro in `pallet-slashing` * Import `vec` in other pallets * Bump TOML dependencies for runtime Haven't fixed the Rust code yet though * Self define types instead of using `node-primitives` * Update staking related configs Values were mostly taken from the Polkadot runtime config * Update `pallet-preimage` config Changes introduced in paritytech/polkadot-sdk#1363 * Add `MaxNominators` to `pallet_babe` Introduced in paritytech/substrate#14471 * Add `MaxNominators` to `pallet_grandpa` Also introduced in paritytech/substrate#14471 * Add `RuntimeFreezeReason` to `pallet_nomination_pools` * Add `MaxTipAmount` to `pallet_tips` Introduced in paritytech/polkadot-sdk#1709 * Add `IdentityInformation` to `pallet_identity` Introduced in paritytech/polkadot-sdk#1661 * finish runtime * Use `crates.io` packages in `entropy` TOML This doesn't compile yet * Remove reference to `node_primitives` * Move imports under correct dependency section These shouldn't be built-deps, my bad * Change `WarpSyncParams` import to come from `sc_network_sync` Change introduced here: paritytech/polkadot-sdk#1912 * Add missing `sc-consensus-babe` package * Remove second generic from `DefaultImportQueue` This was removed in paritytech/substrate#14612 * Add temporary cursed RPC bounds * Switch `sp-consensus-grandpa` to be from Crates * Add Grandpa justification period to service * Rename `justification_period to` `justification_generation_period` * Add missing `block_relay` param Introduced in paritytech/polkadot-sdk#1524 * Try to clean up runtime types * Add `opaque` types to runtime These match what was in `node-primitives`. In particular we're interested in the `Block` type which we were using in a lot of places, and I incorrectly changed to be `Unchechecked` instead of `Opaque`. * Use opaque block type in service * Add full session key impls * Remove cursed trait bounds for RPC * Convert some tabs to spaces Sorry, I had to * Import `Vec` from `sp_std` in benchmarks Turns out the issue responsible for this change is this: paritytech/polkadot-sdk#172 * Pull `TrackedStorageKey` from `sp_storage` From here: paritytech/substrate#14787 * Add `BenchmarkHelper` to treasury pallet * TaploFmt * change max freezes * Sort TOML imports in runtime manifest * Move `version` field to be first in runtime manifest * Organize imports in pallet manifests * Sort and organize imports for client * Address TODOs in `entropy-shared` * Remove TODOs related to `node-primitives` * Pull `substrate-wasm-builder` from crates.io * TaploFmt * Fix benchmarking import post-merge * Fix another program import port-merge * Import `Vec` to programs benches * Wrong vec import 🙃 * Poke CI * Bump node metadata --------- Co-authored-by: Jesse Abramowitz <[email protected]>
…tytech#1912) This PR moves syncing-related code from `sc-network-common` to `sc-network-sync`. Unfortunately, some parts are tightly integrated with networking, so they were left in `sc-network-common` for now: 1. `SyncMode` in `common/src/sync.rs` (used in `NetworkConfiguration`). 2. `BlockAnnouncesHandshake`, `BlockRequest`, `BlockResponse`, etc. in `common/src/sync/message.rs` (used in `src/protocol.rs` and `src/protocol/message.rs`). More substantial refactoring is needed to decouple syncing and networking completely, including getting rid of the hardcoded sync protocol. ## Release notes Move syncing-related code from `sc-network-common` to `sc-network-sync`. Delete `ChainSync` trait as it's never used (the only implementation is accessed directly from `SyncingEngine` and exposes a lot of public methods that are not part of the trait). Some new trait(s) for syncing will likely be introduced as part of Sync 2.0 refactoring to represent syncing strategies.
This PR moves syncing-related code from
sc-network-common
tosc-network-sync
.Unfortunately, some parts are tightly integrated with networking, so they were left in
sc-network-common
for now:SyncMode
incommon/src/sync.rs
(used inNetworkConfiguration
).BlockAnnouncesHandshake
,BlockRequest
,BlockResponse
, etc. incommon/src/sync/message.rs
(used insrc/protocol.rs
andsrc/protocol/message.rs
).More substantial refactoring is needed to decouple syncing and networking completely, including getting rid of the hardcoded sync protocol.
Release notes
Move syncing-related code from
sc-network-common
tosc-network-sync
. DeleteChainSync
trait as it's never used (the only implementation is accessed directly fromSyncingEngine
and exposes a lot of public methods that are not part of the trait). Some new trait(s) for syncing will likely be introduced as part of Sync 2.0 refactoring to represent syncing strategies.Builds upon #1736.