[WIP] test new core and withdrawals #2287
Conversation
|
Warning Rate limit exceeded@shumkov has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 22 minutes and 23 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes in this pull request involve modifications to several configuration and versioning files across the Dash platform. Key updates include the introduction of Docker image specifications for local and testnet configurations, enhancements to withdrawal limit functionalities, and the addition of new version modules. Error handling improvements and task reorganization in the core setup processes are also present, along with the introduction of new constants and modules for version management. Changes
Possibly related issues
Possibly related PRs
Suggested labels
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (12)
packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v2.rs (1)
2-5: Add documentation for the DPP method versions constant.
Please add documentation comments explaining:
- The purpose of
DPP_METHOD_VERSIONS_V2 - The significance of each field value
- Any changes or improvements from the previous version (if applicable)
Example:
+/// DPP Method versions for platform version 2
+///
+/// # Fields
+/// * epoch_core_reward_credits_for_distribution: Controls the distribution of core reward credits per epoch
+/// * daily_withdrawal_limit: Version of the daily withdrawal limit implementation to use
pub const DPP_METHOD_VERSIONS_V2: DPPMethodVersions = DPPMethodVersions {packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/mod.rs (1)
Line range hint 1-11: LGTM! Clean versioning structure.
The code maintains a clear versioning structure with:
- Proper use of feature versioning through
FeatureVersion - Clean separation of versions using modules
- Well-defined structure for method versions
Consider documenting the version transition strategy and compatibility guarantees in the module-level documentation to help maintainers understand when and how to introduce new versions.
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/v1/mod.rs (1)
3-8: Enhance documentation with more details.
The documentation should include:
- The unit conversion explanation (how 2000 Dash translates to 200_000_000_000_000 Credits)
- The precision/decimal places being used
- Any assumptions or constraints
Consider updating the documentation like this:
/// Set constant withdrawal daily limit to 2000 Dash
///
+ /// The limit is converted to Credits using the following calculation:
+ /// 2000 Dash * 10^11 (Credits per Dash)
+ ///
/// # Returns
///
- /// * `Credits`: The calculated daily withdrawal limit based on the available credits.
+ /// * `Credits`: 200,000,000,000,000 Credits (equivalent to 2000 Dash)packages/rs-platform-version/src/version/mod.rs (1)
19-19: Document the V5 Module Changes
The addition of the v5 module should be accompanied by documentation explaining the changes and new features introduced in this version.
Consider adding a module-level documentation comment (///) explaining:
- Key features/changes in V5
- Migration requirements from V4
- Any new constraints or behaviors
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/mod.rs (1)
15-15: Consider future-proofing the version handling mechanism.
While the current implementation is clean and functional, as more versions are added, the match statement approach might become harder to maintain.
Consider these architectural improvements:
- Add documentation explaining the differences between versions
- Consider implementing a trait-based version handling system for better scalability
- Ensure consistent validation across versions (e.g., total_credits_in_platform validation)
Example trait-based approach:
trait WithdrawalLimitStrategy {
fn calculate_limit(&self, total_credits: Credits) -> Result<Credits, ProtocolError>;
}
struct V0Strategy;
struct V1Strategy;
impl WithdrawalLimitStrategy for V0Strategy {
fn calculate_limit(&self, total_credits: Credits) -> Result<Credits, ProtocolError> {
Ok(daily_withdrawal_limit_v0(total_credits))
}
}packages/dashmate/configs/defaults/getLocalConfigFactory.js (1)
27-29: Document the Core v22 upgrade impact.
The upgrade to Core v22 is a significant change that may have compatibility implications.
Please consider:
- Adding a comment explaining the rationale for upgrading to v22
- Documenting any breaking changes or new features in Core v22 that affect this platform
- Including upgrade instructions in the README or migration guide
packages/rs-platform-version/src/version/protocol_version.rs (1)
52-52: Consider deployment impact of new latest version.
The update to LATEST_PLATFORM_VERSION is correct. However, since this affects both latest() and desired() methods, ensure that:
- Deployment processes are ready for the new version
- Runtime behavior changes are documented
- Migration paths are available for existing deployments
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1)
Line range hint 1-200: Consider documenting the versioning strategy.
The codebase implements a comprehensive versioning system for ABCI methods. To improve maintainability:
- Consider adding documentation about the versioning strategy
- Document the criteria for introducing new versions
- Add migration guides between versions
Consider adding a module-level documentation comment explaining:
//! # Drive ABCI Method Versions
//!
//! This module implements versioning for Drive ABCI methods. Each version (v1-v4)
//! represents a set of method implementations that may differ in behavior or interface.
//!
//! ## Version History
//! - v1: Initial implementation
//! - v2: [Document major changes]
//! - v3: [Document major changes]
//! - v4: Core v22 compatibility changes
//!
//! ## Migration
//! When upgrading between versions, ensure all dependent modules are updated accordingly.packages/rs-platform-version/src/version/v5.rs (1)
33-33: Clarify the comment for version changes
The comment mentions that this version contains some fixes for withdrawals. Consider providing more specific details about the fixes or referencing related issues or pull requests for better clarity.
packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs (3)
276-276: Remove TODO comment after implementing the condition.
After adding the necessary condition, remember to remove the TODO comment to keep the codebase clean and maintainable.
Line range hint 319-331: Simplify nested error handling logic.
The error handling within the chain lock verification contains nested match statements, which can make the code harder to read and maintain. Consider refactoring the error handling to use the ? operator where appropriate or to flatten the logic for better readability.
Apply this diff to refactor the error handling:
let VerifyChainLockResult {
chain_lock_signature_is_deserializable,
found_valid_locally,
found_valid_by_core,
core_is_synced,
} = self.verify_chain_lock(
block_state_info.round,
&block_platform_state,
core_chain_lock_update,
true,
platform_version,
)?;By propagating the error using the ? operator, you simplify the control flow:
- Replace explicit error matching with
?, which will return early if an error occurs. - Ensure that only recoverable errors are transformed into validation errors.
Line range hint 406-414: Consider handling potential None values gracefully.
In the code snippet where root_hash is obtained, there is an unwrap followed by a potential mapping of an error:
let root_hash = self
.drive
.grove
.root_hash(Some(transaction), &platform_version.drive.grove_version)
.unwrap()
.map_err(|e| Error::Drive(GroveDB(e)))?;Using unwrap() can cause a panic if root_hash is None. To enhance the robustness of the code, consider handling the Option more safely.
Apply this diff to handle the Option without panicking:
let root_hash = self
.drive
.grove
.root_hash(Some(transaction), &platform_version.drive.grove_version)
- .unwrap()
+ .ok_or_else(|| Error::Drive(GroveDB("Root hash not found".into())))?
.map_err(|e| Error::Drive(GroveDB(e)))?;This change replaces unwrap() with ok_or_else() to provide a custom error message if the Option is None.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (13)
- packages/dashmate/configs/defaults/getLocalConfigFactory.js (1 hunks)
- packages/dashmate/configs/defaults/getTestnetConfigFactory.js (1 hunks)
- packages/dashmate/configs/getConfigFileMigrationsFactory.js (2 hunks)
- packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/mod.rs (1 hunks)
- packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/v1/mod.rs (1 hunks)
- packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs (1 hunks)
- packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/mod.rs (1 hunks)
- packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v2.rs (1 hunks)
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1 hunks)
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs (1 hunks)
- packages/rs-platform-version/src/version/mod.rs (2 hunks)
- packages/rs-platform-version/src/version/protocol_version.rs (2 hunks)
- packages/rs-platform-version/src/version/v5.rs (1 hunks)
🔇 Additional comments (18)
packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/mod.rs (1)
4-4: Verify v2 module implementation.
The addition of the v2 module aligns with the versioning pattern. Let's verify its implementation to ensure proper version management.
✅ Verification successful
✓ v2 module implementation is correctly structured and used
The v2 module is properly implemented with appropriate versioning:
- Follows the same structure as v1 module
- Increments
daily_withdrawal_limitversion from 0 to 1, aligning with PR's withdrawal-related changes - Maintains backward compatibility with existing features
- Correctly used in platform version v5
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the v2 module implementation and its usage
# Check the v2 module implementation
echo "Checking v2 module implementation:"
rg -p "DPP_METHOD_VERSIONS_V2" --type rust
# Check for any migration code that handles version transitions
echo -e "\nChecking version migration code:"
rg -p "v1::.*v2::" --type rust
Length of output: 568
Script:
#!/bin/bash
# Let's gather more information about the v2 module implementation
# Check the content of v2.rs to understand its structure
echo "Content of v2.rs:"
cat packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v2.rs
# Check the DPPMethodVersions struct definition
echo -e "\nDPPMethodVersions struct definition:"
rg -p "struct DPPMethodVersions" --type rust -A 10
# Check where v2 is being used
echo -e "\nUsages of dpp_method_versions::v2:"
rg -p "dpp_method_versions::v2" --type rust
# Check v1 implementation for comparison
echo -e "\nContent of v1.rs (if exists):"
cat packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v1.rs 2>/dev/null || echo "v1.rs not found"
Length of output: 1399
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/v1/mod.rs (1)
1-12: Verify the Credits conversion rate.
The implementation assumes a specific conversion rate between Dash and Credits. Let's verify this is correct across the codebase.
✅ Verification successful
Let me gather more information about the Credits conversion rate by checking the implementation details.
Based on the gathered information, I can now generate the final response.
The Credits conversion rate is correctly implemented
The implementation uses 200_000_000_000_000 Credits for 2000 Dash, which aligns with the platform's conversion rate where:
- 1 Duff = 1000 Credits (defined as
CREDITS_PER_DUFFconstant) - 1 Dash = 100_000_000 Duffs (standard Dash denomination)
- Therefore, 2000 Dash = 2000 * 100_000_000 * 1000 = 200_000_000_000_000 Credits
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other instances of Dash to Credits conversion to verify consistency
rg -g '*.rs' -B 2 -A 2 'Credits.*Dash|Dash.*Credits'
Length of output: 1590
Script:
#!/bin/bash
# Search for Credits type definition and constants
ast-grep --pattern 'type Credits = $_'
# Look for any numeric constants or conversion functions related to Credits
rg -g '*.rs' -B 2 -A 2 '(const|static).*(CREDIT|DASH|[0-9]{9,})'
Length of output: 6519
packages/rs-platform-version/src/version/mod.rs (2)
23-23: Verify Version Constant Usage
The update of LATEST_VERSION to PROTOCOL_VERSION_5 needs careful verification across the codebase.
✅ Verification successful
Let me analyze the output and generate additional verification scripts to better understand the protocol version usage.
Based on the extensive analysis of the codebase, I can now provide a final response regarding the update of LATEST_VERSION to PROTOCOL_VERSION_5:
Protocol Version 5 Update Verification Complete
The update to PROTOCOL_VERSION_5 is properly integrated into the platform's version management system:
- The version is defined in
packages/rs-platform-version/src/version/v5.rswith associated platform configuration - The upgrade mechanism is well-established with proper version compatibility checks and upgrade paths
- The change is supported by comprehensive version upgrade infrastructure including:
- Protocol version voting system
- Version upgrade state tracking
- Version compatibility validation
- Upgrade transition handling
The codebase shows this is a controlled protocol version upgrade with proper safeguards and compatibility checks in place.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify version constant usage and potential impacts
# Check for direct LATEST_VERSION usage
echo "Checking LATEST_VERSION usage..."
rg "LATEST_VERSION" -C 3
# Look for version comparisons that might need updates
echo "Checking version comparisons..."
rg "PROTOCOL_VERSION" -C 3
# Check for version-specific configurations
echo "Checking version-specific configs..."
fd -e toml -e yaml -e json --exec rg -l "version"
Length of output: 287879
Script:
#!/bin/bash
# Check for any direct references to PROTOCOL_VERSION_5 and its usage
rg "PROTOCOL_VERSION_5" -C 3
# Check for any version upgrade or migration code
rg "upgrade.*version|version.*upgrade" -C 3
# Check for version compatibility checks
rg "version.*compatibility|compatibility.*version" -C 3
Length of output: 159710
2-2: Breaking Change: Protocol Version Upgrade to V5
This change represents a significant protocol version upgrade from V4 to V5. While the implementation follows the established pattern, this is a breaking change that requires careful consideration.
Let's verify the readiness for this upgrade:
Please ensure:
- All V5 features are fully implemented and tested
- Migration path from V4 to V5 is documented
- Dependent systems are prepared for the version change
- Release notes are updated to reflect this breaking change
Also applies to: 19-19, 23-23
✅ Verification successful
Let me generate additional scripts to verify the protocol version upgrade implications:
This will help us verify:
- The v5 implementation details and changes
- Version upgrade handling mechanisms
- Version compatibility checks
- Test coverage for version changes
Based on the shell script results, I can now provide a complete analysis of the protocol version upgrade to V5:
Protocol Version 5 Implementation Verified
The upgrade to V5 follows established patterns and includes proper implementation:
- Version 5 is properly defined in
packages/rs-platform-version/src/version/v5.rs:
pub const PROTOCOL_VERSION_5: ProtocolVersion = 5;
pub const PLATFORM_V5: PlatformVersion = PlatformVersion {
protocol_version: PROTOCOL_VERSION_5,
drive: DRIVE_VERSION_V2,
drive_abci: DriveAbciVersion {
structs: DRIVE_ABCI_STRUCTURE_VERSIONS_V1,
methods: DRIVE_ABCI_METHOD_VERSIONS_V4,
withdrawal_constants: DRIVE_ABCI_WITHDRAWAL_CONSTANTS_V2,
}
}- Version upgrade mechanisms are in place:
- Proper version compatibility checks via
COMPATIBILITY_MAP - Upgrade protocol version handling in
upgrade_protocol_version_on_epoch_change - Version validation through
ProtocolVersionValidator
- Withdrawal-specific changes:
- Uses
DRIVE_ABCI_WITHDRAWAL_CONSTANTS_V2 - Comment indicates "This version contains some fixes for withdrawals"
- Upgrade safety:
- Version upgrade happens on epoch boundaries
- Includes version compatibility validation
- Has proper version upgrade voting mechanisms
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for V5-related implementations and potential impacts
# Check if v5 module is properly implemented
echo "Checking v5 module implementation..."
rg -p "mod v5" -A 10
# Look for any TODOs or FIXMEs related to v5 migration
echo "Checking for pending v5 migration tasks..."
rg -i "todo|fixme|hack|xxx" -g "!*.md" -C 3
# Check for version-dependent code that might need updates
echo "Checking version-dependent code..."
rg "PROTOCOL_VERSION|LATEST_VERSION" -C 3
Length of output: 287879
Script:
#!/bin/bash
# Check v5 implementation and changes
echo "Checking v5 module implementation..."
rg -p "pub const PLATFORM_V5" -A 10
# Check version upgrade related code
echo "Checking version upgrade related code..."
rg "upgrade.*version" -g "*.rs" -C 3
# Check version compatibility handling
echo "Checking version compatibility..."
rg "COMPATIBILITY_MAP" -g "*.rs" -C 3
# Check version-related tests
echo "Checking version-related tests..."
rg "test.*version" -g "*.rs" -C 3
Length of output: 249641
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/mod.rs (1)
7-7: LGTM! Clean modular separation of versioned implementations.
The addition of the v1 module follows the established pattern and maintains good separation of concerns.
packages/dashmate/configs/defaults/getLocalConfigFactory.js (1)
27-29: 🛠️ Refactor suggestion
Verify Docker image availability and consider making it configurable.
The hardcoded nightly build dashpay/dashd:22.0.0-nightly.2024.10.29 raises several concerns:
- Using a specific nightly build in default configuration could lead to stability issues
- The image might become unavailable or outdated
Consider these improvements:
- Make the image version configurable through environment variables
- Provide a stable fallback version
core: {
docker: {
- image: 'dashpay/dashd:22.0.0-nightly.2024.10.29',
+ image: process.env.DASHD_IMAGE || 'dashpay/dashd:22.0.0',
},packages/dashmate/configs/defaults/getTestnetConfigFactory.js (1)
27-29: Consider security implications of using nightly builds.
Using a nightly build (22.0.0-nightly.2024.10.29) in the configuration:
- Nightly builds are not recommended for production use
- Date-specific nightly builds might be removed from the registry
- Consider using stable releases or documenting the testing nature of this configuration
packages/rs-platform-version/src/version/protocol_version.rs (2)
22-22: LGTM!
The import statement follows the established pattern and is properly placed with other version imports.
38-44: Verify version-dependent code compatibility.
The addition of PLATFORM_V5 to PLATFORM_VERSIONS looks good. However, we should verify that all version-dependent code in the codebase properly handles this new version.
✅ Verification successful
Let me analyze the code further to verify the impact of PLATFORM_V5 addition.
Based on the analysis of the code, I can now provide a final response:
The addition of PLATFORM_V5 appears safe and properly integrated.
The code review shows:
- The platform version system is well-structured with proper version checks and transitions
- Version-dependent code has clear checks (e.g.
if platform_version.protocol_version >= 4) - There is a dedicated transition system for version upgrades with proper validation
- The version upgrade state is tracked and managed through proper channels
- No specific version-dependent features are tied to version 5 yet, making this a clean version number addition
The key evidence supporting this:
- The version system uses a consistent pattern for version checks
- Version transitions are handled explicitly (e.g.
transition_to_version_4) - Feature flags and version checks are properly gated
- The version upgrade state tracking system is in place
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for version-dependent code patterns that might need updates
# for the new PLATFORM_V5.
echo "Searching for version comparisons and matches..."
rg -A 3 "match.*protocol_version|if.*protocol_version|match.*PlatformVersion|when.*version"
echo "Searching for version-specific configurations or features..."
rg -A 3 "cfg\(.*version|feature\(.*version"
Length of output: 193812
Script:
#!/bin/bash
# Search for version-dependent code patterns that might need updates for PLATFORM_V5
# Search for protocol version checks and version-specific logic
echo "Searching for protocol version checks..."
rg -A 3 "protocol_version.*>= |protocol_version.*== |protocol_version.*< |protocol_version.*<= |protocol_version.*!= "
# Search for version-specific feature flags and configurations
echo "Searching for version-specific feature flags..."
rg -A 3 "feature_version|check_version|get_version|version_number"
# Search for version-specific migrations or transitions
echo "Searching for version transitions..."
rg -A 3 "transition_to_version|perform_version|upgrade_version"
Length of output: 221925
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1)
6-6: Verify the v4 module implementation.
The addition of v4 module suggests significant changes to ABCI methods. Since this PR is testing Core v22, ensure that:
- All necessary method versions are properly defined in v4
- Breaking changes are properly documented
- Migration path from v3 to v4 is clear
✅ Verification successful
Let me analyze the v4 implementation and compare it with the previous context to generate a final response.
Implementation looks complete with proper versioning
The v4 module implementation appears well-structured and complete, with versioning information for all ABCI components. Notable observations:
- Most methods maintain version 0, indicating backward compatibility
- Key changes in withdrawal-related functionality:
pool_withdrawals_into_transactions_queue: 1(updated)update_owner_withdrawal_address: 1(updated)
- Protocol upgrade and validator set components also show version increments:
check_for_desired_protocol_upgrade: 1validator_set_update: 1
The implementation aligns with the PR's objectives for Core v22 and withdrawal changes, with clear versioning for modified components.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the v4 module implementation and its differences from v3
# Test 1: Check if v4.rs exists and compare with v3
echo "Comparing v3 and v4 implementations:"
fd "v[34].rs$" --exec diff -u {} {.}
# Test 2: Look for any TODOs or FIXMEs in v4
echo -e "\nChecking for TODOs/FIXMEs in v4:"
rg -i "todo|fixme|xxx|hack" $(fd "v4.rs$")
# Test 3: Check for any breaking changes in method signatures
echo -e "\nChecking for potential breaking changes:"
ast-grep --pattern 'pub const DRIVE_ABCI_METHOD_VERSIONS_V4: DriveAbciMethodVersions'
Length of output: 16109
packages/dashmate/configs/getConfigFileMigrationsFactory.js (1)
7-7: LGTM: Import of NETWORK_DEVNET constant.
The addition of the NETWORK_DEVNET constant is correctly imported and used in the migration logic.
packages/rs-platform-version/src/version/v5.rs (4)
31-31: LGTM on PROTOCOL_VERSION_5 declaration
The declaration of PROTOCOL_VERSION_5 is correct and follows the established pattern.
67-69: LGTM on consensus versioning
The consensus versioning appears correct and consistent.
59-61:
Possible mismatch between comment and method version
The comment states that daily_withdrawal_limit was changed to v1 to increase the limit to 2000 Dash, but the methods field is set to DPP_METHOD_VERSIONS_V2. Please confirm that the correct version is applied.
Run the following script to confirm the version of daily_withdrawal_limit in DPP_METHOD_VERSIONS_V2:
#!/bin/bash
# Description: Verify the version of `daily_withdrawal_limit`.
# Test: Search for the method version definition. Expect: Correct version number.
rg 'pub.*daily_withdrawal_limit.*=' -A 539-42:
Inconsistency between comment and method version
The comment indicates that pool_withdrawals_into_transactions_queue was changed to v1, but the methods field is set to DRIVE_ABCI_METHOD_VERSIONS_V4. Please verify if the correct version is being used.
Run the following script to check the version of pool_withdrawals_into_transactions_queue in DRIVE_ABCI_METHOD_VERSIONS_V4:
✅ Verification successful
No inconsistency - comment and version are correct
Looking at the code, I can confirm that pool_withdrawals_into_transactions_queue is indeed set to version 1 in DRIVE_ABCI_METHOD_VERSIONS_V4, which matches the comment stating it was changed to v1. The comment accurately reflects the implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the version of `pool_withdrawals_into_transactions_queue`.
# Test: Search for the method version definition. Expect: Correct version number.
rg 'pub.*pool_withdrawals_into_transactions_queue.*=' -A 5
Length of output: 136
Script:
#!/bin/bash
# Let's try different approaches to find the version information
# Search for DRIVE_ABCI_METHOD_VERSIONS_V4 definition
rg "DRIVE_ABCI_METHOD_VERSIONS_V4" -B 2 -A 5
# Also search for pool_withdrawals pattern with more flexible matching
rg "pool_withdrawals.*queue" -B 2 -A 5
# Search for any version-related constants or structs
rg "MethodVersions|METHOD_VERSIONS" -B 2 -A 5
Length of output: 336801
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs (2)
38-43: Inconsistent Version Numbers in Masternode Updates
Within the masternode_updates section, some methods have their version numbers set to 1 (e.g., create_owner_identity at line 38 and update_owner_withdrawal_address at line 43), while others remain at 0. Please verify that these version increments are intentional and consistently reflect changes in the method implementations.
14-121: Overall Structure Appears Correct
The DRIVE_ABCI_METHOD_VERSIONS_V4 constant is well-defined, and the method versions are organized appropriately across the different sections. The structure enhances clarity for version management within the ABCI framework.
packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs (1)
Line range hint 19-24: Ensure all function calls include the new epoch_info parameter.
The function signature of run_block_proposal_v0 now includes the additional parameter epoch_info. To prevent compilation errors and ensure consistent behavior, verify that all calls to this function across the codebase have been updated to include the new parameter.
Run the following script to identify any outdated function calls:
Also applies to: 273-276, 287-292
✅ Verification successful
All calls to run_block_proposal_v0 include the epoch_info parameter
The verification shows that the only call site of run_block_proposal_v0 in packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs correctly includes the epoch_info parameter, matching the function signature in v0/mod.rs. No outdated function calls were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find calls to `run_block_proposal_v0` missing the `epoch_info` parameter.
# Expected results: All calls should match the new signature with `epoch_info`.
# Search for function calls that have only six arguments instead of seven.
ast-grep --pattern $'run_block_proposal_v0($_, $_, $_, $_, $_, $_)' \
--ignore 'run_block_proposal_v0($_, $_, $_, $_, $_, $_, $_)'
Length of output: 377
Script:
#!/bin/bash
# Let's try a different approach using ripgrep to find all calls to run_block_proposal_v0
rg "run_block_proposal_v0\(" -A 2 -B 2
Length of output: 1133
Script:
#!/bin/bash
# Let's examine the full function signature and its call site
rg "run_block_proposal_v0" -A 10 packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs
rg "run_block_proposal_v0" -A 10 packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs
Length of output: 1953
| epoch_core_reward_credits_for_distribution: 0, | ||
| daily_withdrawal_limit: 1, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using named constants instead of magic numbers.
The values 0 and 1 would be more maintainable and self-documenting if defined as named constants.
+/// No core reward credits distribution
+const NO_CORE_REWARD_CREDITS: u32 = 0;
+/// Initial version of daily withdrawal limit
+const DAILY_WITHDRAWAL_LIMIT_V1: u32 = 1;
+
pub const DPP_METHOD_VERSIONS_V2: DPPMethodVersions = DPPMethodVersions {
- epoch_core_reward_credits_for_distribution: 0,
- daily_withdrawal_limit: 1,
+ epoch_core_reward_credits_for_distribution: NO_CORE_REWARD_CREDITS,
+ daily_withdrawal_limit: DAILY_WITHDRAWAL_LIMIT_V1,
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| epoch_core_reward_credits_for_distribution: 0, | |
| daily_withdrawal_limit: 1, | |
| /// No core reward credits distribution | |
| const NO_CORE_REWARD_CREDITS: u32 = 0; | |
| /// Initial version of daily withdrawal limit | |
| const DAILY_WITHDRAWAL_LIMIT_V1: u32 = 1; | |
| epoch_core_reward_credits_for_distribution: NO_CORE_REWARD_CREDITS, | |
| daily_withdrawal_limit: DAILY_WITHDRAWAL_LIMIT_V1, |
| pub fn daily_withdrawal_limit_v1() -> Credits { | ||
| // 2000 Dash | ||
| 200_000_000_000_000 | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve maintainability by using constants.
The magic number makes the code harder to maintain and understand. Consider using constants to make the calculation clear and adjustable.
Consider this refactoring:
+/// Number of Credits per Dash
+const CREDITS_PER_DASH: u64 = 100_000_000_000;
+
+/// Daily withdrawal limit in Dash
+const DAILY_WITHDRAWAL_LIMIT_DASH: u64 = 2_000;
+
pub fn daily_withdrawal_limit_v1() -> Credits {
- // 2000 Dash
- 200_000_000_000_000
+ DAILY_WITHDRAWAL_LIMIT_DASH * CREDITS_PER_DASH
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| pub fn daily_withdrawal_limit_v1() -> Credits { | |
| // 2000 Dash | |
| 200_000_000_000_000 | |
| } | |
| /// Number of Credits per Dash | |
| const CREDITS_PER_DASH: u64 = 100_000_000_000; | |
| /// Daily withdrawal limit in Dash | |
| const DAILY_WITHDRAWAL_LIMIT_DASH: u64 = 2_000; | |
| pub fn daily_withdrawal_limit_v1() -> Credits { | |
| DAILY_WITHDRAWAL_LIMIT_DASH * CREDITS_PER_DASH | |
| } |
| docker: { | ||
| image: 'dashpay/dashd:22.0.0-nightly.2024.10.29', | ||
| }, |
There was a problem hiding this comment.
💡 Codebase verification
Docker image version inconsistency detected across configuration files
The verification revealed inconsistent Core versions in configuration files:
getTestnetConfigFactory.jsandgetLocalConfigFactory.jsuse v22.0.0-nightly.2024.10.29getBaseConfigFactory.jsuses v21
This inconsistency needs to be addressed as it could lead to unexpected behavior when different configurations are used.
🔗 Analysis chain
Verify Docker image version consistency across configurations.
The Docker image configuration is properly structured. Let's ensure the version is consistent across all configuration files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistency in Docker image versions across config files
# Expected: All configs should use the same Core v22 nightly build
echo "Checking Docker image versions in config files:"
rg -A 1 "docker: {" packages/dashmate/configs/
rg "image: 'dashpay/dashd:" packages/dashmate/configs/
Length of output: 633
| '1.3.0-dev.3': (configFile) => { | ||
| Object.entries(configFile.configs) | ||
| .forEach(([, options]) => { | ||
| if ([NETWORK_LOCAL, NETWORK_TESTNET, NETWORK_DEVNET].includes(options.network)) { | ||
| options.core.docker.image = 'dashpay/dashd:22.0.0-nightly.2024.10.29'; | ||
| } | ||
| }); | ||
| return configFile; | ||
| }, |
There was a problem hiding this comment.
Critical: Remove duplicate migration version.
There are two migrations with the same version '1.3.0-dev.3'. This will cause issues as only one migration can be executed for a given version:
- The first migration (around line 1000) updates multiple configuration settings including core log settings and Docker images
- This duplicate migration only updates the core Docker image
This creates a conflict where either:
- One migration will override the other
- The migration system might fail due to the duplicate version
Either:
- Remove this duplicate migration and merge its functionality into the existing '1.3.0-dev.3' migration, or
- Create a new migration with a different version number (e.g., '1.3.0-dev.4')
Here's how to merge it into the existing migration:
'1.3.0-dev.3': (configFile) => {
Object.entries(configFile.configs)
.forEach(([, options]) => {
options.platform.drive.abci.docker.image = 'dashpay/drive:1-dev';
options.platform.dapi.api.docker.image = 'dashpay/dapi:1-dev';
+ // Update core docker image for specific networks
+ if ([NETWORK_LOCAL, NETWORK_TESTNET, NETWORK_DEVNET].includes(options.network)) {
+ options.core.docker.image = 'dashpay/dashd:22.0.0-nightly.2024.10.29';
+ }
// Update core log settings
options.core.log.filePath = null;
// ... rest of the existing migration
});
return configFile;
},
-'1.3.0-dev.3': (configFile) => {
- Object.entries(configFile.configs)
- .forEach(([, options]) => {
- if ([NETWORK_LOCAL, NETWORK_TESTNET, NETWORK_DEVNET].includes(options.network)) {
- options.core.docker.image = 'dashpay/dashd:22.0.0-nightly.2024.10.29';
- }
- });
- return configFile;
-},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| '1.3.0-dev.3': (configFile) => { | |
| Object.entries(configFile.configs) | |
| .forEach(([, options]) => { | |
| if ([NETWORK_LOCAL, NETWORK_TESTNET, NETWORK_DEVNET].includes(options.network)) { | |
| options.core.docker.image = 'dashpay/dashd:22.0.0-nightly.2024.10.29'; | |
| } | |
| }); | |
| return configFile; | |
| }, | |
| '1.3.0-dev.3': (configFile) => { | |
| Object.entries(configFile.configs) | |
| .forEach(([, options]) => { | |
| options.platform.drive.abci.docker.image = 'dashpay/drive:1-dev'; | |
| options.platform.dapi.api.docker.image = 'dashpay/dapi:1-dev'; | |
| // Update core docker image for specific networks | |
| if ([NETWORK_LOCAL, NETWORK_TESTNET, NETWORK_DEVNET].includes(options.network)) { | |
| options.core.docker.image = 'dashpay/dashd:22.0.0-nightly.2024.10.29'; | |
| } | |
| // Update core log settings | |
| options.core.log.filePath = null; | |
| // ... rest of the existing migration | |
| }); | |
| return configFile; | |
| }, |
| perform_events_on_first_block_of_protocol_change: Some(0), | ||
| protocol_version_upgrade_percentage_needed: 67, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Clarify the Use of Constants in Versioning
In the protocol_upgrade section, the fields perform_events_on_first_block_of_protocol_change (line 50) and protocol_version_upgrade_percentage_needed (line 51) include a Some(0) and a numeric value 67, respectively, instead of version numbers like other methods. Consider separating constants or optional values from method version definitions for clearer code organization.
| verify_chain_lock_locally: 0, | ||
| verify_chain_lock_through_core: 0, | ||
| make_sure_core_is_synced_to_chain_lock: 0, | ||
| recent_block_count_amount: 2, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Separate Constants from Method Versions in Core Chain Lock
At line 63, the recent_block_count_amount is assigned a numeric value 2 within the core_chain_lock method versions. For better readability and maintainability, it might be beneficial to define constants separately from method version structures.
| // We do that before we mark withdrawals as expired | ||
| // to rebroadcast them on the next block but not the same | ||
| // one | ||
| // TODO: It must be also only on core height change |
There was a problem hiding this comment.
Implement condition to rebroadcast expired withdrawals only on core height change.
The TODO comment indicates that rebroadcast_expired_withdrawal_documents should be called only when there is a core height change. Currently, the function is called unconditionally, which may lead to unnecessary operations. Consider adding a condition to check for a core height change before calling the function.
Apply this diff to implement the condition:
// We do that before we mark withdrawals as expired
// to rebroadcast them on the next block but not the same
// one
// TODO: It must be also only on core height change
+ if block_state_info.core_chain_locked_height() != last_block_core_height {
self.rebroadcast_expired_withdrawal_documents(
&block_info,
last_committed_platform_state,
transaction,
platform_version,
)?;
+ }Committable suggestion was skipped due to low confidence.
…signing # Conflicts: # packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs # packages/rs-platform-version/src/version/v5.rs
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (8)
packages/rs-platform-version/src/version/v5.rs (2)
33-33: Consider adding more specific documentation about withdrawal fixes.The current comment "This version contains some fixes for withdrawals" could be more descriptive. Consider detailing:
- What specific withdrawal issues were fixed
- Any breaking changes in withdrawal behavior
- Impact on existing withdrawal functionality
Line range hint
34-65: Consider documenting the versioning strategy.The platform configuration uses a mix of different version numbers across components (V1 through V4). This could make it challenging to:
- Track component compatibility
- Understand which components need updates
- Plan future version upgrades
Consider:
- Documenting the versioning strategy for different components
- Adding a compatibility matrix
- Explaining why some components remain at V1 while others are upgraded
packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs (2)
18-24: Enhance error constant documentation.While the comments indicate the Core version changes, they could be more descriptive about the specific scenarios that trigger these errors.
Consider expanding the comments to explain:
- What conditions trigger each error
- The difference between "no active quorum" vs "too old quorum"
- The timing constraints that lead to the "expired" error
Line range hint
18-99: Consider version compatibility strategy.The current implementation handles errors from both Core v21 and v22. While this provides backward compatibility, consider:
- Adding version detection to use appropriate error handling based on the Core version
- Documenting the migration path from v21 to v22
- Planning for eventual removal of v21 error handling
This will help maintain cleaner code and make future upgrades smoother.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs (1)
82-85: Reference the associated issue or PR for version changeThe comment explains the change of
pool_withdrawals_into_transactions_queueto version1to address validator quorum adjustments related to a Core v21 bug. For better traceability and future maintenance, consider referencing the specific issue number or pull request that details this change.packages/dashmate/src/listr/tasks/setup/local/configureCoreTaskFactory.js (3)
116-124: Correct grammatical error in task titleIn the task title on line 116, consider changing "Generating funds to use as a collateral for masternodes" to "Generating funds to use as collateral for masternodes" for grammatical correctness.
Line range hint
126-214: Refactor duplicated code in activation tasksThe code for 'Activating v19 and v20' and 'Activating v21 fork' tasks is largely similar. To enhance maintainability and reduce code duplication, consider extracting the common logic into a reusable function or helper.
Here's a suggested refactor:
+ function activateFork(ctx, activationHeight) { + return new Observable(async (observer) => { + const blocksToGenerateInOneStep = 10; + let blocksGenerated = 0; + let { result: currentBlockHeight } = await ctx.coreService.getRpcClient().getBlockCount(); + do { + ({ result: currentBlockHeight } = await ctx.coreService.getRpcClient().getBlockCount()); + await generateBlocks( + ctx.coreService, + blocksToGenerateInOneStep, + NETWORK_LOCAL, + (blocks) => { + blocksGenerated += blocks; + observer.next(`${blocksGenerated} blocks generated`); + }, + ); + } while (activationHeight > currentBlockHeight); + observer.next(`Activated fork at height ${activationHeight}`); + observer.complete(); + return this; + }); + }Then, replace the tasks with:
- { - title: 'Activating v19 and v20', - task: () => new Observable(async (observer) => { - const dip3ActivationHeight = 901; - // existing code... - }), - }, + { + title: 'Activating v19 and v20', + task: () => activateFork(ctx, 901), + },And for 'Activating v21 fork':
- { - title: 'Activating v21 fork', - task: () => new Observable(async (observer) => { - const dip3ActivationHeight = 1001; - // existing code... - }), - }, + { + title: 'Activating v21 fork', + task: () => activateFork(ctx, 1001), + },Also applies to: 312-338
Line range hint
126-214: Rename variable 'dip3ActivationHeight' for clarityIn both activation tasks, consider renaming the variable
dip3ActivationHeighttoactivationHeightto more accurately reflect its purpose, as it pertains to various fork activation heights, not just DIP3.Also applies to: 312-338
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
packages/dashmate/templates/core/dash.conf.dotis excluded by!**/*.dot
📒 Files selected for processing (9)
packages/dashmate/configs/getConfigFileMigrationsFactory.js(2 hunks)packages/dashmate/src/listr/tasks/setup/local/configureCoreTaskFactory.js(3 hunks)packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs(3 hunks)packages/rs-drive-abci/src/rpc/core.rs(0 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs(1 hunks)packages/rs-platform-version/src/version/mod.rs(2 hunks)packages/rs-platform-version/src/version/v5.rs(2 hunks)packages/rs-platform-version/src/version/v6.rs(1 hunks)
💤 Files with no reviewable changes (1)
- packages/rs-drive-abci/src/rpc/core.rs
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs
- packages/rs-platform-version/src/version/mod.rs
🔇 Additional comments (11)
packages/rs-platform-version/src/version/v6.rs (4)
1-29: LGTM! Well-organized imports and clear version increment.
The imports are logically grouped and the protocol version increment is clear.
37-40: Verify Core version compatibility.
The comment indicates this fixes a Core v21 bug, but the PR objectives mention testing with Core v22. Please verify:
- That this change is still necessary/compatible with Core v22
- Whether this should be documented in breaking changes
57-59: Significant change: Verify withdrawal limit increase.
Increasing the daily withdrawal limit to 2000 Dash is a significant change that warrants careful consideration:
- Has this limit been approved by stakeholders?
- Are there any security implications?
- Should this be prominently documented in breaking changes?
Consider adding rate limiting or additional security measures to protect against potential abuse of the increased limit.
65-67: Verify Tenderdash consensus version compatibility.
Given this PR is testing Core v22 compatibility:
- Confirm if Tenderdash consensus version 1 is compatible with Core v22
- Verify if any consensus version updates are needed
✅ Verification successful
Let me search for more context about Core v22 compatibility and version requirements.
Based on the search results, I can see that Tenderdash consensus version 1 was introduced in v3 and has been maintained through v5 and v6. Let me search for any Core v22 specific compatibility requirements.
Based on the evidence gathered from the codebase:
- Tenderdash consensus version 1 was introduced in v3 and has been maintained consistently through v5 and v6 without changes
- The code shows no specific Core v22 compatibility requirements for consensus versions
- The changelog shows only Tenderdash software version updates but no consensus version changes
Tenderdash consensus version 1 is compatible with Core v22. No consensus version updates are needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for Tenderdash version references and compatibility checks
rg -A 5 "tenderdash_consensus_version"
Length of output: 6081
Script:
#!/bin/bash
# Search for Core v22 related version information
rg -i "core.*v22|version.*22"
# Search for any version compatibility documentation
fd README.md | xargs cat
# Search for version upgrade documentation or comments
rg -i "upgrade|version.*change" packages/rs-platform-version/src/
Length of output: 107189
Script:
#!/bin/bash
# Search for Core v22 compatibility info in version files
rg -i "core.*v22|version.*22" packages/rs-platform-version/src/
# Search for any consensus version compatibility docs
fd README.md packages/rs-platform-version/ | xargs cat
# Search for any consensus version changes in changelog
rg -i "consensus.*version|tenderdash.*version" CHANGELOG.md
Length of output: 716
packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs (2)
4-4: LGTM!
The import statement correctly brings in the required constant for transaction error handling.
98-99: Verify error handling coverage.
The error handling looks comprehensive, covering both old and new Core error cases. However, let's verify that these are all possible error codes from Core v22.
✅ Verification successful
Let me verify the error handling by checking the actual error handling implementation to ensure all error codes are properly handled.
Let me check the actual error handling implementation to see how these error codes are used.
Let me try a different approach to find the error handling implementation.
Error handling is correctly implemented and comprehensive
The error handling implementation properly covers all three Core error cases for asset unlock transactions:
bad-assetunlock-not-active-quorum(Core 21)bad-assetunlock-too-old-quorum(Core 22 replacement)bad-assetunlock-too-late(expiration case)
All these errors are handled in the same way - logging the failure and storing the transaction for potential retry, which is the appropriate behavior for these cases.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any other asset unlock error codes we might have missed
rg -g '!target' -g '*.rs' "bad-assetunlock"
Length of output: 702
Script:
#!/bin/bash
# Get the full context of error handling implementation
rg -g '!target' -g '*.rs' -B 5 -A 10 "bad-assetunlock"
Length of output: 3694
Script:
#!/bin/bash
# Search for the error handling implementation
rg -g '!target' -g '*.rs' -A 20 -B 5 "match.*error" packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs
Length of output: 184
Script:
#!/bin/bash
# Get more context around where these error constants are used
rg -g '!target' -g '*.rs' -A 30 -B 10 "CORE_RPC_ERROR_ASSET_UNLOCK" packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs
Length of output: 3993
packages/dashmate/configs/getConfigFileMigrationsFactory.js (2)
7-7: LGTM!
The addition of NETWORK_DEVNET constant is properly placed with other network-related imports.
1034-1036: 🛠️ Refactor suggestion
Verify the use of nightly build in production.
The migration updates the core docker image to a nightly build (22.0.0-nightly.2024.10.29) for local, testnet, and development networks. Using nightly builds in production environments (testnet) could introduce stability risks.
Run the following script to check if this nightly version is being used in other configurations:
Consider parameterizing the version to make future updates easier:
- options.core.docker.image = 'dashpay/dashd:22.0.0-nightly.2024.10.29';
+ const CORE_VERSION = process.env.CORE_VERSION || '22.0.0-nightly.2024.10.29';
+ options.core.docker.image = `dashpay/dashd:${CORE_VERSION}`;packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs (2)
50-52: Confirm the usage of Some(0) and constant value
In the protocol_upgrade section, the field perform_events_on_first_block_of_protocol_change is set to Some(0), which differs from the usual integer versioning pattern. Additionally, protocol_version_upgrade_percentage_needed is assigned a value of 67, representing a percentage rather than a version number. Please verify that these assignments are intentional and compatible with the DriveAbciProtocolUpgradeMethodVersions struct.
14-124: Consistent and comprehensive method version definitions
The DRIVE_ABCI_METHOD_VERSIONS_V5 constant is well-structured, with method versions consistently defined across all categories. This detailed organization enhances readability and facilitates effective version management.
packages/dashmate/src/listr/tasks/setup/local/configureCoreTaskFactory.js (1)
95-113: Wallet creation task implemented correctly
The 'Create wallet' task parameters are appropriately set, and the wallet creation logic aligns with the expected usage.
| @@ -6,13 +6,15 @@ use crate::version::dpp_versions::dpp_document_versions::v1::DOCUMENT_VERSIONS_V | |||
| use crate::version::dpp_versions::dpp_factory_versions::v1::DPP_FACTORY_VERSIONS_V1; | |||
| use crate::version::dpp_versions::dpp_identity_versions::v1::IDENTITY_VERSIONS_V1; | |||
| use crate::version::dpp_versions::dpp_method_versions::v1::DPP_METHOD_VERSIONS_V1; | |||
| use crate::version::dpp_versions::dpp_method_versions::v2::DPP_METHOD_VERSIONS_V2; | |||
There was a problem hiding this comment.
💡 Codebase verification
Remove unused imports
The following imports are not used in the PLATFORM_V5 configuration and should be removed:
DPP_METHOD_VERSIONS_V2(line 9)DRIVE_ABCI_METHOD_VERSIONS_V3(line 17)
The code shows that:
DPP_METHOD_VERSIONS_V1is used in the configuration (line 71)DRIVE_ABCI_METHOD_VERSIONS_V4is used in the configuration (line 39)
🔗 Analysis chain
Verify unused imports and version consistency.
There appear to be some inconsistencies in the version imports:
DPP_METHOD_VERSIONS_V2is imported butDPP_METHOD_VERSIONS_V1is used inPLATFORM_V5DRIVE_ABCI_METHOD_VERSIONS_V3is imported butDRIVE_ABCI_METHOD_VERSIONS_V4is used inPLATFORM_V5
Also applies to: 17-17
Let me verify the actual usage of these versions in the PLATFORM_V5 configuration.
Let me try a different approach to find the PLATFORM_V5 constant.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify if these versions are used elsewhere in the codebase
echo "Checking for DPP_METHOD_VERSIONS_V2 usage:"
rg "DPP_METHOD_VERSIONS_V2" -A 5
echo -e "\nChecking for DRIVE_ABCI_METHOD_VERSIONS_V3 usage:"
rg "DRIVE_ABCI_METHOD_VERSIONS_V3" -A 5
Length of output: 6284
Script:
#!/bin/bash
# Check the actual version usage in PLATFORM_V5
rg "PLATFORM_V5\s*=.*\{" packages/rs-platform-version/src/version/v5.rs -A 20
Length of output: 79
Script:
#!/bin/bash
# Check the content of v5.rs to see the actual usage
cat packages/rs-platform-version/src/version/v5.rs
Length of output: 4064
| /// This version contains some fixes for withdrawals. | ||
| pub const PLATFORM_V5: PlatformVersion = PlatformVersion { |
There was a problem hiding this comment.
💡 Codebase verification
Incorrect naming of platform version constant
There is a clear inconsistency in v6.rs where PLATFORM_V5 is defined but uses PROTOCOL_VERSION_6. Looking at the pattern across all version files:
v1.rs:PLATFORM_V1usesprotocol_version: 1v2.rs:PLATFORM_V2usesprotocol_version: 2v3.rs:PLATFORM_V3usesprotocol_version: 3v4.rs:PLATFORM_V4usesPROTOCOL_VERSION_4v5.rs:PLATFORM_V5usesPROTOCOL_VERSION_5v6.rs:PLATFORM_V5usesPROTOCOL_VERSION_6(incorrect)
The constant should be renamed to PLATFORM_V6 to maintain consistency with the established pattern where platform version matches protocol version.
🔗 Analysis chain
Clarify version naming inconsistency.
The constant is named PLATFORM_V5 but uses PROTOCOL_VERSION_6. This naming inconsistency could be confusing. Consider either:
- Renaming to
PLATFORM_V6to match the protocol version - Adding a comment explaining why platform and protocol versions differ
Let's search specifically for these version constants to understand the naming pattern and verify if there's really an inconsistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any other potential version inconsistencies
rg -A 1 "PLATFORM_V\d+"
rg -A 1 "PROTOCOL_VERSION_\d+"
Length of output: 6081
Script:
#!/bin/bash
# Search for platform version constants and protocol version references
rg -A 2 "PLATFORM_V\d+\s*=|PLATFORM_V\d+:" packages/rs-platform-version/src/
rg -A 2 "PROTOCOL_VERSION_\d+|protocol_version:\s*\d+" packages/rs-platform-version/src/
Length of output: 7098
| // This error replaced the previous since Core 22 to make it more verbose | ||
| const CORE_RPC_ERROR_ASSET_UNLOCK_TOO_OLD_QUORUM: &str = " bad-assetunlock-too-old-quorum"; |
There was a problem hiding this comment.
Fix typo in error constant.
The constant has a leading space which could cause comparison issues.
-const CORE_RPC_ERROR_ASSET_UNLOCK_TOO_OLD_QUORUM: &str = " bad-assetunlock-too-old-quorum";
+const CORE_RPC_ERROR_ASSET_UNLOCK_TOO_OLD_QUORUM: &str = "bad-assetunlock-too-old-quorum";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // This error replaced the previous since Core 22 to make it more verbose | |
| const CORE_RPC_ERROR_ASSET_UNLOCK_TOO_OLD_QUORUM: &str = " bad-assetunlock-too-old-quorum"; | |
| // This error replaced the previous since Core 22 to make it more verbose | |
| const CORE_RPC_ERROR_ASSET_UNLOCK_TOO_OLD_QUORUM: &str = "bad-assetunlock-too-old-quorum"; |
Feature branch for testing Core v22 and withdrawal changes
Contains #2107 and #2286
Issue being fixed or feature implemented
What was done?
How Has This Been Tested?
Breaking Changes
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
Release Notes
New Features
PROTOCOL_VERSION_6and related constants.Bug Fixes
Refactor
Documentation