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

feat(client): implement ClientOperationCfg to control any client oper… #2696

Merged
merged 2 commits into from
Feb 5, 2025

Conversation

RolandSherwin
Copy link
Member

No description provided.

@@ -22,7 +22,6 @@ color-eyre = "0.6.3"
crdts = { version = "7.3", default-features = false, features = ["merkle"] }
custom_debug = "~0.6.1"
dirs-next = "~2.0.0"
exponential-backoff = "2.0.0"
Copy link
Member

Choose a reason for hiding this comment

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

Very good that we removed that from the protocol layer!

Comment on lines 53 to 118
pub struct ChunkOperationConfig {
/// The retry strategy to use if we fail to store a chunk. Every write will also verify that the chunk
/// is stored on the network by fetching it back.
///
/// Use the `verification_quorum` and `verification_retry_strategy` to configure the verification operation.
pub(crate) write_retry_strategy: RetryStrategy,
/// The number of chunks to wait for before considering the read after write operation successful.
pub(crate) verification_quorum: ResponseQuorum,
/// The retry strategy to use if the read after write operation fails.
pub(crate) verification_retry_strategy: RetryStrategy,
/// The number of chunks to wait for before considering the read operation successful.
pub(crate) read_quorum: ResponseQuorum,
/// The retry strategy to use if the read operation fails.
pub(crate) read_retry_strategy: RetryStrategy,
}

#[derive(Debug, Clone)]
pub struct GraphOperationConfig {
/// The retry strategy to use if we fail to store a graph entry. Every write will also verify that the entry
/// is stored on the network by fetching it back.
///
/// Use the `verification_quorum` and `verification_retry_strategy` to configure the verification operation.
pub(crate) write_retry_strategy: RetryStrategy,
/// The number of entries to wait for before considering the read after write operation successful.
pub(crate) verification_quorum: ResponseQuorum,
/// The retry strategy to use if the read after write operation fails.
pub(crate) verification_retry_strategy: RetryStrategy,
/// The number of entries to wait for before considering the read operation successful.
pub(crate) read_quorum: ResponseQuorum,
/// The retry strategy to use if the read operation fails.
pub(crate) read_retry_strategy: RetryStrategy,
}

#[derive(Debug, Clone)]
pub struct PointerOperationConfig {
/// The retry strategy to use if we fail to store a pointer. Every write will also verify that the pointer
/// is stored on the network by fetching it back.
///
/// Use the `verification_quorum` and `verification_retry_strategy` to configure the verification operation.
pub(crate) write_retry_strategy: RetryStrategy,
/// The number of pointers to wait for before considering the read after write operation successful.
pub(crate) verification_quorum: ResponseQuorum,
/// The retry strategy to use if the read after write operation fails.
pub(crate) verification_retry_strategy: RetryStrategy,
/// The number of pointers to wait for before considering the read operation successful.
pub(crate) read_quorum: ResponseQuorum,
/// The retry strategy to use if the read operation fails.
pub(crate) read_retry_strategy: RetryStrategy,
}

#[derive(Debug, Clone)]
pub struct ScratchpadOperationConfig {
/// The retry strategy to use if we fail to store a scratchpad. Every write will also verify that the scratchpad
/// is stored on the network by fetching it back.
///
/// Use the `verification_quorum` and `verification_retry_strategy` to configure the verification operation.
pub(crate) write_retry_strategy: RetryStrategy,
/// The number of scratchpads to wait for before considering the read after write operation successful.
pub(crate) verification_quorum: ResponseQuorum,
/// The retry strategy to use if the read after write operation fails.
pub(crate) verification_retry_strategy: RetryStrategy,
/// The number of scratchpads to wait for before considering the read operation successful.
pub(crate) read_quorum: ResponseQuorum,
/// The retry strategy to use if the read operation fails.
pub(crate) read_retry_strategy: RetryStrategy,
}
Copy link
Member

Choose a reason for hiding this comment

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

Those are exactly the same please make this one type. If in the future we need to make them different, we will. But for now, please let's keep this simple.

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated. But this would mean that we lose the ability to set the cfgs in one place. We reuse the configs at some places and those might be prone to errors.

Copy link
Member

Choose a reason for hiding this comment

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

Ok will address that in a follow up then

Comment on lines -259 to +243
evm_network: config.evm_network,
evm_network: Arc::new(config.evm_network),
operation_config: Arc::new(config.operation_config),
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need Arc here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Every component Network is arc'ed to be freely clonable without incurring much cost, so I assume we'd want to do the same for Clients.

Comment on lines 91 to 97
// Client Configs
config::ChunkOperationConfig,
config::ClientConfig,
config::ClientOperationConfig,
config::GraphOperationConfig,
config::PointerOperationConfig,
config::ScratchpadOperationConfig,
Copy link
Member

Choose a reason for hiding this comment

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

Making this one type will make the exposed types much simpler, 6 exposed public structs related to config is huge

Copy link
Member

@grumbach grumbach left a comment

Choose a reason for hiding this comment

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

Thanks for making this PR @RolandSherwin! Apart form the config types duplication LGTM!

@RolandSherwin RolandSherwin force-pushed the uploader_metrics_1_config branch from 88d5572 to 37bfc3d Compare February 4, 2025 22:50
Copy link
Member

@grumbach grumbach left a comment

Choose a reason for hiding this comment

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

✅ 🚢

@grumbach grumbach added this pull request to the merge queue Feb 5, 2025
Merged via the queue into maidsafe:main with commit 6035b2d Feb 5, 2025
25 checks passed
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.

2 participants