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

Str 786 main refactor part1 #561

Merged
merged 7 commits into from
Jan 3, 2025
Merged

Str 786 main refactor part1 #561

merged 7 commits into from
Jan 3, 2025

Conversation

bewakes
Copy link
Contributor

@bewakes bewakes commented Dec 25, 2024

Description

This is the part 1 of main refactor which moves around a couple of things:

  1. Move db init to rocksdb-store crate
  2. Move Config to crates/config as it is where it should be. Corresponding minor changes to ReaderConfig and Args methods.
  3. Adds NodeStorage, which at the moment consolidates two managers. It will get extended and included in the context in future.
  4. Expose Handle from TaskManager and use it instead of passing around runtime everywhere.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Refactor
  • New or updated tests
  • Dependency Update

Notes to Reviewers

This is a part of bigger refactor that lies ahead and I kindly request to review this as soon as possible.

Checklist

  • I have performed a self-review of my code.
  • I have commented my code where necessary.
  • I have updated the documentation if needed.
  • My changes do not introduce new warnings.
  • I have added tests that prove my changes are effective or that my feature works.
  • New and existing tests pass with my changes.

Related Issues

@bewakes bewakes requested review from a team as code owners December 25, 2024 10:28
@bewakes bewakes force-pushed the STR-786-main-refactor-part1 branch 2 times, most recently from 61486b8 to 95d94a5 Compare December 26, 2024 05:50
@bewakes bewakes requested a review from a team as a code owner December 26, 2024 05:50
Copy link

codecov bot commented Dec 26, 2024

Codecov Report

Attention: Patch coverage is 26.43312% with 231 lines in your changes missing coverage. Please review.

Project coverage is 56.50%. Comparing base (7b9d76c) to head (78c20dd).
Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
bin/strata-client/src/args.rs 0.00% 82 Missing ⚠️
crates/rocksdb-store/src/lib.rs 0.00% 58 Missing ⚠️
bin/strata-client/src/main.rs 0.00% 25 Missing ⚠️
bin/strata-client/src/helpers.rs 0.00% 21 Missing ⚠️
crates/storage/src/lib.rs 0.00% 17 Missing ⚠️
crates/btcio/src/reader/config.rs 0.00% 7 Missing ⚠️
crates/tasks/src/manager.rs 0.00% 6 Missing ⚠️
crates/consensus-logic/src/sync_manager.rs 0.00% 5 Missing ⚠️
bin/strata-client/src/l1_reader.rs 0.00% 4 Missing ⚠️
crates/config/src/config.rs 95.34% 4 Missing ⚠️
... and 1 more
@@           Coverage Diff           @@
##             main     #561   +/-   ##
=======================================
  Coverage   56.50%   56.50%           
=======================================
  Files         314      316    +2     
  Lines       31957    31959    +2     
=======================================
+ Hits        18057    18059    +2     
  Misses      13900    13900           
Files with missing lines Coverage Δ
crates/bridge-relay/src/relayer.rs 34.46% <ø> (ø)
crates/config/src/bridge.rs 100.00% <100.00%> (ø)
crates/consensus-logic/src/checkpoint.rs 0.00% <ø> (ø)
crates/consensus-logic/src/csm/worker.rs 0.00% <ø> (ø)
crates/primitives/src/relay/types.rs 61.20% <ø> (-0.22%) ⬇️
crates/evmexec/src/fork_choice_state.rs 0.00% <0.00%> (ø)
bin/strata-client/src/l1_reader.rs 0.00% <0.00%> (ø)
crates/config/src/config.rs 95.34% <95.34%> (ø)
crates/consensus-logic/src/sync_manager.rs 0.00% <0.00%> (ø)
crates/tasks/src/manager.rs 85.29% <0.00%> (-1.03%) ⬇️
... and 6 more

... and 2 files with indirect coverage changes

@bewakes bewakes force-pushed the STR-786-main-refactor-part1 branch 2 times, most recently from 0b95080 to c555431 Compare December 26, 2024 08:47
Comment on lines 67 to 73
pub fn derive_config(&self) -> Result<Config, String> {
let args = self.clone();
Ok(Config {
bitcoind_rpc: BitcoindConfig {
rpc_url: args
.bitcoind_host
.ok_or_else(|| "args: no bitcoin --rpc-url provided".to_string())?,
Copy link
Contributor

Choose a reason for hiding this comment

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

I would make this a toplevel function or even like from_args on Config, it doesn't really make sense to be a member function on Args. This also makes some sense to use anyhow instead of manipulating string error messages.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea behind this was that Args seems to be more inside the bin whereas Config seems somewhere common which other crates can/do use. To me, it doesn't make sense to pull in Arg dependency where config is defined.

I think config should not be in bin. It is just being used everywhere so it makes sense to keep it somewhere common and it should not have dependency on Args.

Copy link
Contributor

Choose a reason for hiding this comment

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

If we're separating the actual service config from the inner client/node config internally then yeah moving it apart makes sense.

But how these fns are organized here does feel weird to me.

Comment on lines +134 to +121
pub fn update_config(&self, config: &mut Config) {
let args = self.clone();
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, doesn't make sense to be a member function on Args.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same reasoning as above.

Comment on lines 120 to 123
rpc_url: args.reth_authrpc.unwrap_or("".to_string()), // TODO: sensible default
secret: args.reth_jwtsecret.unwrap_or_default(), /* TODO: probably
* secret should be
* Option */
Copy link
Contributor

Choose a reason for hiding this comment

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

There is no sensible default here and we always need a secret. We're not at the point where we can run without reth, so make these required.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh these, I haven't had a change to go through in detail. These were just being moved around. Will make it required.

crates/storage/src/managers/mod.rs Outdated Show resolved Hide resolved
crates/storage/src/managers/mod.rs Outdated Show resolved Hide resolved
Comment on lines +144 to +145
pub type CommonDb =
CommonDatabase<L1Db, L2Db, SyncEventDb, ClientStateDb, ChainstateDb, RBCheckpointDB>;
Copy link
Contributor

Choose a reason for hiding this comment

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

I would like to get rid of this CommonDatabase abstraction since it's not useful anymore. But since there's a lot of stuff still using the Database trait I'm not sure how feasible that is yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The feasibility is yet to be assessed. Once things are in place where they should be, we can then get rid of the stuffs.

Copy link
Contributor

Choose a reason for hiding this comment

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

This crate is for things that are common to every possible service, like logging. This configuration is specific to the strata client. Do you think it makes sense move it to a new node crate like Reth has and shift more init logic there?

Copy link
Contributor Author

@bewakes bewakes Dec 27, 2024

Choose a reason for hiding this comment

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

Yes, I think that would be better. I've mentioned the rationale behind this in one of the comments above.

I am also working on a new crate, in a different branch, which I've named as "client". But I do like the name "node" more.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So yeah, let's keep Config under common as it is fairly serves its purpose(being "common" to almost all other crates in some ways). Can move to node crate in the subsequent PRs.

Copy link
Contributor

Choose a reason for hiding this comment

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

No it doesn't serve its purpose. That's just not what the crate is intended for.

Copy link
Contributor

Choose a reason for hiding this comment

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

The term "common" refers to what's shared underlying infra between all of the binaries.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's not a consensus-related type like what the primitives crate is for.

Yes as I said before it would make sense to have a new node crate like Reth has.

because reader, writer, bridge, etc have their configs derived from this Config.

But we don't want to make btcio dependent on this new node crate, the node crate makes sense to be dependent on btcio instead. The btcio services have their own configuration that we build from our config.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we have a new crate config? Well, do you agree that Config should be somewhere outside of bin?

Copy link
Contributor

Choose a reason for hiding this comment

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

It just makes sense in that node crate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thought some more and decided to have a new config crate. This way, crates depending on config don't have to pull in the node crate.

Copy link
Contributor

Choose a reason for hiding this comment

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

What would be depending on this config crate but not the node crate?

@bewakes bewakes force-pushed the STR-786-main-refactor-part1 branch from c555431 to c870a11 Compare December 27, 2024 10:04
@bewakes bewakes enabled auto-merge December 27, 2024 10:57
@bewakes bewakes requested review from a team as code owners January 1, 2025 07:06
@bewakes bewakes requested a review from delbonis January 1, 2025 08:00
@bewakes bewakes force-pushed the STR-786-main-refactor-part1 branch from dcab80f to 76a8c03 Compare January 2, 2025 08:36
Copy link
Contributor

@delbonis delbonis left a comment

Choose a reason for hiding this comment

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

Ok I think I'm fine with this as-is. It's still a work in progress but this is an improvement.

@sapinb sapinb disabled auto-merge January 3, 2025 11:39
@sapinb sapinb merged commit ef1097b into main Jan 3, 2025
16 of 18 checks passed
@sapinb sapinb deleted the STR-786-main-refactor-part1 branch January 3, 2025 11:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants