Skip to content
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

Refactor common code among clients #316

Merged
merged 33 commits into from
Nov 24, 2023
Merged

Refactor common code among clients #316

merged 33 commits into from
Nov 24, 2023

Conversation

nanocryk
Copy link
Contributor

@nanocryk nanocryk commented Nov 7, 2023

Adds a new crate which factors out common code between all clients, and allow to easily add node specific services.

@@ -115,6 +122,27 @@ thread_local!(static TIMESTAMP: std::cell::RefCell<u64> = std::cell::RefCell::ne
/// Provide a mock duration starting at 0 in millisecond for timestamp inherent.
/// Each call will increment timestamp by slot_duration making Aura think time has passed.
struct MockTimestampInherentDataProvider;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be moved to node_common as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends on the SLOT_DURATION in the runtimes, but we can probably be generic over it.

Comment on lines +284 to +285
/// Can only be called once on a `NodeBuilder` that doesn't have yet network
/// data.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like this, I knew it can be done using const generics and a state machine enum, but I didn't know about the TypeIdentity trick, will need to look into it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the "Typestate Pattern" described here: http://cliffle.com/blog/rust-typestate/

Usually you need an impl block per typestate, but core_extensions::TypeIdentity allows to state that a type parameter is equal to a concrete type and convert between both, which allow to have a single impl block with where clauses on the functions. (except for new, as it doesn't take self Rust is unable to infer which type to use, even if there is only 1 type T implementing TypeIdentity<Type = T>)


let telemetry = telemetry.map(|(worker, telemetry)| {
task_manager
.spawn_handle()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not this spawn telemetry?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does. Why?

/// Can only be called once on a `NodeBuilder` that doesn't have yet network
/// data.
#[must_use]
pub fn build_substrate_network(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I cannot call together both build_substrate_network and build_cumulus_network right? I wonder whether this can be an enum as an argument, where in the case of type:

pub struct CumulusNetwork {
para_id: ParaId,
relay_chain_interface: RelayChainInterface
}
pub enum NetworkType {
Substrate,
Cumulus(CumulusNetwork)
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This enum would need to be generic over the RelayChainInterface type, which means that in Substrate mode it will not be able to infer the type and will require to explicitly name one.

Copy link
Contributor

github-actions bot commented Nov 16, 2023

Coverage Report

(master)

@@                     Coverage Diff                     @@
##           master   jeremy-refactor-clients      +/-   ##
===========================================================
- Coverage   71.37%                    71.33%   -0.04%     
+ Files          86                        89       +3     
- Lines       19709                     19592     -117     
===========================================================
- Hits        14067                     13974      -93     
- Misses       5642                      5618      -24     
Files Changed Coverage
/client/consensus/src/consensus_orchestrator.rs 77.46% (-0.44%) 🔽
/container-chains/templates/frontier/node/src/chain_spec.rs 71.74% (-3.02%) 🔽
/container-chains/templates/frontier/node/src/command.rs 20.59% (-0.12%) 🔽
/container-chains/templates/frontier/node/src/service.rs 76.77% (-1.18%) 🔽
/node/src/command.rs 15.51% (-0.06%) 🔽
/node/src/service.rs 17.72% (-14.28%) 🔽

Coverage generated Fri Nov 24 15:31:12 UTC 2023

@nanocryk nanocryk added the B5-clientnoteworthy Changes should be mentioned in any downstream projects' release notes label Nov 20, 2023
@nanocryk nanocryk marked this pull request as ready for review November 20, 2023 15:22
@nanocryk
Copy link
Contributor Author

Left-over for future PRs:

  • Add dev service to simple template
  • Maybe factor out common command stuff?

@girazoki girazoki added the breaking Needs to be mentioned in breaking changes label Nov 20, 2023
@tmpolaczyk
Copy link
Contributor

tmpolaczyk commented Nov 21, 2023

Something in container_chain_spawner.rs is not right, the test pnpm moonwall test zombie_tanssi_keep_db is failing. Looking into it.

Edit: nevermind, it's failing on master as well. Will try to fix it and submit a pr.

Edit2: #335

Copy link
Contributor

@tmpolaczyk tmpolaczyk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tanssi-node and container_chain_spawner look good, I didn't check the templates.

@tmpolaczyk
Copy link
Contributor

Can you resolve conflicts and merge? Thanks

@nanocryk nanocryk merged commit 4ce0936 into master Nov 24, 2023
24 checks passed
@nanocryk nanocryk deleted the jeremy-refactor-clients branch November 24, 2023 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B5-clientnoteworthy Changes should be mentioned in any downstream projects' release notes breaking Needs to be mentioned in breaking changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants