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

fix(cli): Fix and clean client modes and fetch presets #279

Merged
merged 31 commits into from
Sep 30, 2024
Merged

Conversation

antiyro
Copy link
Member

@antiyro antiyro commented Sep 23, 2024

No description provided.

@antiyro antiyro self-assigned this Sep 23, 2024
@antiyro antiyro added bug Something isn't working enhancement New feature or request labels Sep 23, 2024
@antiyro antiyro changed the title fix(cli): Fix and clean client modes + fix db columns for metrics fix(cli): Fix and clean client modes and fetch presets Sep 23, 2024
@antiyro antiyro marked this pull request as ready for review September 23, 2024 12:31
Copy link
Member

@cchudant cchudant left a comment

Choose a reason for hiding this comment

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

list of stuff from #255 i'd like reverted/changed:

  • revert the set_workdir addition in the tests
  • update the example config file
  • revert the built in configs to functions like
    pub fn starknet_sepolia() -> Self {
        Self {
            chain_name: "Starknet Sepolia".into(),
            chain_id: ChainId::Sepolia,
            eth_core_contract_address: eth_core_contract_address::SEPOLIA_TESTNET.parse().expect("parsing a constant"),
            ..Self::starknet_mainnet()
        }
    }

and they do not need to return results
The preset can just use those functions instead of reading any file

  • remove any fs read except in tests, and when the chain config file is supplied as argument
  • please add this comment at the top of chain_config.rs
// Note: We are NOT using fs read for constants, as they NEED to be included in the resulting
// binary. Otherwise, using the madara binary without cloning the repo WILL crash, and that's very very bad.
// The binary needs to be self contained! We need to be able to ship madara as a single binary, without
// the user needing to clone the repo.
// Only use `fs` for constants when writing tests.
  • change the chain config override system (see my comment below)
  • Duration parsing needs to accept 2s, 200ms -- stings like that, and should not accept naked numbers. Change all the cli that currently accept durations to that format too.
  • I think we should not use test config for devnet, but a config named devnet. The test preset can be removed as it's only used in tests using ChainConfig::test_config
  • there are a few except and error handling stuff that could be better handled.

self.get_preset_name()
);
let remote_url = match self {
ChainPreset::Mainnet => "https://raw.githubusercontent.com/madara-alliance/madara/main/crates/primitives/chain_config/presets/mainnet.yaml",
Copy link
Member

Choose a reason for hiding this comment

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

id prefer if we used include bytes here please
or, i think it's just better to revert all of it - remake the functions as they were before

    pub fn starknet_sepolia() -> Self {
        Self {
            chain_name: "Starknet Sepolia".into(),
            chain_id: ChainId::Sepolia,
            eth_core_contract_address: eth_core_contract_address::SEPOLIA_TESTNET.parse().expect("parsing a constant"),
            ..Self::starknet_mainnet()
        }
    }

like that
it's much better i think, we really dont need to parse a file here

Copy link
Member

Choose a reason for hiding this comment

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

Reverted the read file stuff!

None => {
ChainConfig::from_yaml(&self.chain_config_path.clone().expect("Failed to retrieve chain config path"))?
let path = self.chain_config_path.clone().ok_or_else(|| {
Copy link
Member

Choose a reason for hiding this comment

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

can we just support --devnet without specifying any kind of preset please

Copy link
Member Author

Choose a reason for hiding this comment

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

Why would you want that, we would like to have custom devnets also (the kkt use case were they need to custom steps is already a use case for that)

Copy link
Member

Choose a reason for hiding this comment

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

well, i think --devnet without --chain-config implies --preset devnet

Copy link
Member

@akhercha akhercha Sep 27, 2024

Choose a reason for hiding this comment

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

--devnet alone is now accepted - preset will be devnet by default & it's still possible to specify another config

}
// Override stuff if flag is set
let chain_config =
if self.chain_config_override { self.chain_params.override_cfg(chain_config) } else { chain_config };
Copy link
Member

Choose a reason for hiding this comment

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

id prefer if you remade the chain config override system from scratch and follow how i described it in #240

which means, no new cli struct or field by field override by hand

Copy link
Member

@akhercha akhercha Sep 27, 2024

Choose a reason for hiding this comment

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

As said in DMs, I've tried to implement a different override mechanism but it's far from perfect at the moment because ChainConfig doesn't implement Serialize (since our flow is 1. generate ChainConfig 2. override if possible , we need to convert the pre-built ChainConfig to Value).

Instead of going down the rabbit hole of implementing wrapper structs around Blockifiers one & implementing Serialize myself, I've created a wrapper struct OverridableChainConfig that represents the fields we're able to override.

I'm not really fan of this tbh but it works at least. Any thoughts? Implementing Serialize would appear the cleanest here probably but didn't try yet - can do if you judge it better

Arc::new(ForwardToProvider::new(SequencerGatewayProvider::new(
run_cmd
.network
.expect(
Copy link
Member

Choose a reason for hiding this comment

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

use context not expect here please

Copy link
Member

Choose a reason for hiding this comment

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

doneeee

@cchudant
Copy link
Member

i think preset can be moved to node cli args and not inside the primitive crate altogether -- to a clap enum. It would allow clap to show a proper error message when the preset is unknown, with a list of the possible values. Much better UX

@cchudant
Copy link
Member

also, i dont know what the default impl on ChainConfig means, try to remove it and see if it was useful
(i just dont know why it's there it feels weird)

@antiyro
Copy link
Member Author

antiyro commented Sep 25, 2024

This PR will be handled by @akhercha from now on

@akhercha
Copy link
Member

akhercha commented Sep 27, 2024

Everything's done, just not sure about the ChainConfig overrides as I said above + this comment:

  • update the example config file

Wdym? I updated the comments inside but happy to do more. @cchudant

@@ -9,8 +9,8 @@ versioned_constants:
"0.13.2": "crates/primitives/chain_config/resources/versioned_constants_13_2.json"
eth_core_contract_address: "0xE2Bb56ee936fd6433DC0F6e7e3b8365C906AA057"
latest_protocol_version: "0.13.2"
block_time: 360
pending_block_update_time: 2
block_time: "6min"
Copy link
Member Author

Choose a reason for hiding this comment

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

why 6mins block time over chain configs, we have around 30sec avg on mainnet

Copy link
Member

Choose a reason for hiding this comment

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

Not sure, it was like this before - but updated to 30s, u're right!

@@ -30,5 +30,5 @@ bouncer_config:
message_segment_length: 18446744073709551615
n_events: 18446744073709551615
state_diff_size: 131072
sequencer_address: "0x123"
sequencer_address: "0x211b748338b39fe8fa353819d457681aa50ac598a3db84cacdd6ece0a17e1f3"
Copy link
Member Author

Choose a reason for hiding this comment

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

what is this address exactly?

Copy link
Member

Choose a reason for hiding this comment

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

Woops, it was meant to be used for the test config. Removed!

Copy link
Member Author

@antiyro antiyro left a comment

Choose a reason for hiding this comment

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

Tested locally and lgtm

@@ -30,5 +30,5 @@ bouncer_config:
message_segment_length: 18446744073709551615
n_events: 18446744073709551615
state_diff_size: 131072
sequencer_address: "0x123"
sequencer_address: "0x0"
Copy link
Member Author

Choose a reason for hiding this comment

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

Sequencer address cannot be zero for block production. We should use another one for the devnet config

Copy link
Member

Choose a reason for hiding this comment

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

done!

Copy link
Member

@akhercha akhercha left a comment

Choose a reason for hiding this comment

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

LGTM

@antiyro antiyro merged commit e2c92eb into main Sep 30, 2024
6 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants