-
Notifications
You must be signed in to change notification settings - Fork 14
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: single-node quorum type 111 #1008
base: v1.5-dev
Are you sure you want to change the base?
Conversation
WalkthroughThe pull request introduces several updates across multiple files, primarily focusing on dependency version upgrades in the Changes
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration 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.
Actionable comments posted: 1
🧹 Nitpick comments (2)
internal/blocksync/synchronizer.go (1)
117-121
: Consider adding validation for negative timeout values.The
WithSyncTimeout
function should validate that the timeout value is positive to prevent potential issues.func WithSyncTimeout(timeout time.Duration) OptionFunc { return func(v *Synchronizer) { + if timeout <= 0 { + timeout = defaultSyncTimeout + } v.syncTimeout = timeout } }node/node.go (1)
Line range hint
1-1000
: Consider breaking down the makeNode functionThe makeNode function is quite large (>500 lines) and handles multiple responsibilities. Consider breaking it down into smaller, more focused functions for better maintainability.
Some suggestions:
- Extract reactor creation into separate functions
- Group related initialization logic
- Consider using the builder pattern for node creation
Example refactor:
func makeNode(ctx context.Context, cfg *config.Config, ...) (service.Service, error) { node := &nodeImpl{} if err := node.initializeBasicServices(ctx, cfg); err != nil { return nil, err } if err := node.initializeReactors(ctx, cfg); err != nil { return nil, err } if err := node.initializeValidatorServices(ctx, cfg); err != nil { return nil, err } return node, nil }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
config/config.go
(2 hunks)config/config_test.go
(1 hunks)config/toml.go
(1 hunks)internal/blocksync/reactor.go
(5 hunks)internal/blocksync/synchronizer.go
(4 hunks)node/node.go
(1 hunks)
🔇 Additional comments (7)
config/config_test.go (1)
27-28
: LGTM: Test coverage added for SyncTimeout default value.
The test correctly verifies that the default sync timeout is set to 60 seconds, matching the defaultSyncTimeout
constant.
internal/blocksync/reactor.go (2)
33-33
: LGTM: Good refactoring of sync timeout configuration.
The constant rename to defaultSyncTimeout
better reflects its purpose, and the new syncTimeout
field in the Reactor
struct enables runtime configuration of the timeout value.
Also applies to: 65-66
112-116
: LGTM: Clean implementation of the builder pattern.
The WithSyncTimeout
method follows the builder pattern correctly, allowing for fluent configuration of the sync timeout.
internal/blocksync/synchronizer.go (2)
73-74
: LGTM: Clean implementation of configurable sync timeout.
The syncTimeout
field is well-documented, and the WithSyncTimeout
option function follows the established pattern for configuration.
Also applies to: 117-121
251-251
: LGTM: Good use of configurable timeout in sync logic.
The WaitForSync
method correctly uses the configured timeout, and the log message helpfully shows the remaining time until timeout.
Also applies to: 258-258
config/toml.go (1)
140-144
: LGTM: Well-documented configuration option
The sync-timeout configuration is properly documented with clear default value and purpose.
node/node.go (1)
370-370
:
Implementation for quorum type 111 is missing
The PR objectives mention implementing support for single-node quorum type 111, but there are no changes related to this in the codebase. Please ensure the quorum type implementation is included.
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
config/config.go (1)
237-241
: Enhance the documentation for SyncTimeout field.The documentation could be more descriptive about what happens after the timeout expires. Consider adding details about the behavior when switching to consensus.
// SyncTimeout is the timeout for the initial sync process, before switching to consensus. + // After this timeout expires, the node will proceed with consensus regardless of the sync state. // // Default: 60s SyncTimeout time.Duration `mapstructure:"sync-timeout"`
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
config/config.go
(3 hunks)config/toml.go
(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- config/toml.go
🔇 Additional comments (3)
config/config.go (3)
259-259
: LGTM!
The default value initialization is correct and consistent with the documentation.
363-366
: LGTM! Validation logic properly implemented.
The validation logic correctly checks for negative values and includes a descriptive error message.
237-241
: Verify the usage of SyncTimeout configuration.
Let's verify how this configuration field is used in the codebase.
✅ Verification successful
Based on the search results, I can now generate a final response as the usage of SyncTimeout
is well documented in the codebase.
SyncTimeout configuration is properly integrated and used
The configuration field is correctly integrated across the codebase:
- Used in
internal/blocksync/reactor.go
with a default value of 60 seconds - Properly passed from node configuration to the block sync reactor via
WithSyncTimeout
- Utilized in the
Synchronizer
component through dependency injection - Has validation in
config.ValidateBasic()
to ensure non-negative values
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check where and how SyncTimeout is used in the codebase
# Search for SyncTimeout usage in the codebase
echo "Searching for SyncTimeout usage..."
rg -A 5 "SyncTimeout"
# Search for specific sync timeout related function calls
echo "Searching for sync timeout related function calls..."
rg -A 5 "NewReactor.*SyncTimeout|NewSynchronizer.*timeout"
Length of output: 4199
Issue being fixed or feature implemented
We need support for quorum type 111, which is single-node quorum.
What was done?
sync-timeout
to config file,How Has This Been Tested?
Tested as part of dash platform development, dashpay/platform#2392
Breaking Changes
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
Summary by CodeRabbit