feat: final abci state sync #2486
Conversation
WalkthroughThis pull request introduces broad updates across several components. The default version of Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant App
participant SnapshotManager
participant Database
Client->>App: offer_snapshot(request)
App->>SnapshotManager: Validate snapshot & acquire lock
SnapshotManager->>Database: Wipe DB/init new sync session
Database-->>SnapshotManager: Acknowledge DB update
SnapshotManager-->>App: New snapshot session established
App-->>Client: Return ResponseOfferSnapshot
Suggested reviewers
Poem
✨ Finishing Touches
🪧 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: 6
🧹 Nitpick comments (47)
packages/rs-drive/src/error/drive.rs (1)
191-194: Add a more descriptive docstring for theSnapshoterror variant.The current docstring "Error todo" is temporary placeholder text. Consider replacing it with a detailed description explaining when and why this error variant would be used.
Also, consider including the string message in the error display format for better debugging:
-/// Error todo -#[error("snapshot error")] +/// Error related to snapshot operations such as creating, listing, or loading snapshots +#[error("snapshot error: {0}")] Snapshot(String),packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs (1)
165-174: Added handler for version 1 block proposal executionThe code properly extends the version handling by adding case
1to callrun_block_proposal_v1with the same parameters as the v0 implementation. This follows good versioning practices by maintaining backward compatibility while adding new functionality.However, the error message in the
UnknownVersionMismatchhasn't been updated to include version 1 in theknown_versionslist.Update the error message to include both supported versions:
version => Err(Error::Execution(ExecutionError::UnknownVersionMismatch { method: "run_block_proposal".to_string(), - known_versions: vec![0], + known_versions: vec![0, 1], received: version, })),packages/rs-drive-abci/src/abci/handler/info.rs (1)
25-31: Enhanced logging for block height and platform stateAdded detailed tracing that logs both block height and platform state, which improves observability. This will be helpful for debugging state sync issues.
Note that the block height is already being extracted on line 33, so this introduces a duplicate calculation of
last_committed_block_height(). While this doesn't affect functionality, it's a minor efficiency concern.Consider refactoring to avoid the duplicate call:
let platform_state = app.platform().state.load(); - let block_height = platform_state.last_committed_block_height(); + let block_height = platform_state.last_committed_block_height() as i64; tracing::trace!( block_height, platform_state = ?platform_state, "state_info" ); - let last_block_height = platform_state.last_committed_block_height() as i64; + let last_block_height = block_height;packages/rs-drive/src/drive/platform_state/store_reduced_platform_state_bytes/mod.rs (1)
10-10: Consider enhancing the method documentation.This docstring could be more specific about what "reduced platform state bytes" represents and its expected structure to help new developers understand the system better.
packages/rs-drive/src/drive/platform_state/store_last_block_info_bytes/mod.rs (1)
10-10: Consider enhancing the method documentation.The current docstring is generic. It would be more helpful to provide specific details about what "last block info bytes" contains and its expected structure.
packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/mod.rs (2)
7-8: Consider consistent module placement across files.In other similar files (
store_reduced_platform_state_bytes/mod.rsandstore_last_block_info_bytes/mod.rs), the module declaration comes before imports. Consider maintaining a consistent style across all files.
10-10: Enhance method documentation for clarity.This docstring could be more specific about what exactly is being fetched from storage and its expected structure to improve developer understanding.
packages/rs-drive/src/drive/platform_state/store_last_block_info_bytes/v0/mod.rs (1)
1-29: Consider adding documentationThis method lacks documentation comments explaining its purpose, parameters, and return value. Adding rustdoc comments would improve code maintainability and make it easier for other developers to understand the function's role in the state synchronization process.
impl Drive { + /// Stores the last block information bytes in the database. + /// + /// # Arguments + /// + /// * `last_block_info_bytes` - The serialized last block information + /// * `transaction` - The transaction argument for the database operation + /// * `platform_version` - The platform version + /// + /// # Returns + /// + /// * `Ok(())` if the operation was successful + /// * `Err(Error)` if the operation failed pub(super) fn store_last_block_info_bytes_v0( &self, last_block_info_bytes: &[u8], transaction: TransactionArg, platform_version: &PlatformVersion, ) -> Result<(), Error> {packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/v0/mod.rs (3)
1-1: Unused import
REDUCED_PLATFORM_STATE_KEYis imported but not used in this file.-use crate::drive::platform_state::{LAST_BLOCK_INFO_KEY, REDUCED_PLATFORM_STATE_KEY}; +use crate::drive::platform_state::LAST_BLOCK_INFO_KEY;
17-17: Unnecessary clone operationThe query is cloned on line 17 but is only used once, making the clone unnecessary.
- let path_query = PathQuery::new_unsized(misc_path_vec(), query.clone()); + let path_query = PathQuery::new_unsized(misc_path_vec(), query);
1-38: Add method documentationConsider adding rustdoc comments to explain the method's purpose, parameters, and return values.
impl Drive { + /// Fetches the last block information bytes from the database. + /// + /// # Arguments + /// + /// * `transaction` - The transaction argument for the database operation + /// * `platform_version` - The platform version + /// + /// # Returns + /// + /// * `Ok(Some(Vec<u8>))` if the last block info exists + /// * `Ok(None)` if the last block info doesn't exist + /// * `Err(Error)` if an error occurred during the operation pub(super) fn fetch_last_block_info_bytes_v0( &self, transaction: TransactionArg, platform_version: &PlatformVersion, ) -> Result<Option<Vec<u8>>, Error> {packages/rs-drive-abci/src/execution/storage/store_last_block_info/v0/mod.rs (3)
5-7: Unused importsThe imports for
PlatformSerializable,ReducedPlatformSerializable, andProtocolErrorare not used in this file.-use dpp::serialization::{PlatformSerializable, ReducedPlatformSerializable}; -use dpp::version::PlatformVersion; -use dpp::ProtocolError; +use dpp::version::PlatformVersion;
19-23: Improve error messageThe error message "corrupted last block_info serialisation" doesn't accurately describe what happened. The serialization didn't become corrupted; it failed.
let block_info_bytes = bincode::encode_to_vec(block_info, config).map_err(|_| { Error::Drive(drive::error::Error::Drive(CorruptedDriveState( - "corrupted last block_info serialisation".to_string(), + "failed to serialize last block info".to_string(), ))) })?;
12-28: Add method documentationConsider adding rustdoc comments to explain the method's purpose, parameters, and error handling.
+ /// Stores the last block information by serializing the BlockInfo and calling store_last_block_info_bytes. + /// + /// # Arguments + /// + /// * `block_info` - The block information to store + /// * `transaction` - The transaction argument for the database operation + /// * `platform_version` - The platform version + /// + /// # Returns + /// + /// * `Ok(())` if successful + /// * `Err(Error)` if serialization fails or storage fails pub(super) fn store_last_block_info_v0( &self, block_info: &BlockInfo, transaction: TransactionArg, platform_version: &PlatformVersion, ) -> Result<(), Error> {packages/rs-dpp/src/reduced_platform_state/mod.rs (3)
2-2: Unused import
PlatformSerializableis imported but not used in this file.-use crate::serialization::{PlatformSerializable, ReducedPlatformDeserializable}; +use crate::serialization::ReducedPlatformDeserializable;
18-38: Add version check for forward compatibilityThe deserialization method doesn't check or enforce compatibility with the provided platform version. Consider adding version validation to ensure forward compatibility.
fn versioned_deserialize( data: &[u8], platform_version: &PlatformVersion, ) -> Result<Self, ProtocolError> where Self: Sized, { + // Check if platform_version supports the reduced platform state format + if !platform_version.dpp.reduced_platform_state_enabled { + return Err(ProtocolError::UnsupportedFeature( + "Reduced platform state is not enabled for this platform version".to_string(), + )); + } + let config = config::standard().with_big_endian().with_no_limit(); let reduced_platform_state_in_save_format: ReducedPlatformStateForSaving = bincode::decode_from_slice(data, config)
14-16: Add serialization implementationThe
ReducedPlatformDeserializabletrait is implemented, but there's no corresponding implementation for serialization. Consider implementing theReducedPlatformSerializabletrait to provide a complete interface.Consider implementing the serialization counterpart:
impl ReducedPlatformSerializable for ReducedPlatformStateForSaving { fn reduced_serialize(&self, platform_version: &PlatformVersion) -> Result<Vec<u8>, ProtocolError> { let config = config::standard().with_big_endian().with_no_limit(); let data = bincode::encode_to_vec(self, config).map_err(|e| { ProtocolError::PlatformSerializationError(format!( "unable to serialize ReducedPlatformStateForSaving: {}", e )) })?; Ok(data) } }packages/rs-drive-abci/src/abci/handler/list_snapshots.rs (2)
19-21: Redundant logging - console log and tracingThere's both a
println!and atracing::trace!statement with the same message. This creates redundant logging that can clutter logs and decrease performance.- println!("[state_sync] api list_snapshots called"); tracing::trace!("[state_sync] api list_snapshots called");Using the tracing framework alone provides better control over log levels and formatting.
31-47: Consider moving helper functions out of the main function scopeThe
convert_snapshotsandcheckpoint_existsfunctions are defined within thelist_snapshotsfunction. While this works, it would be more maintainable to define these as separate functions, especially if they might be reused elsewhere.Consider moving these helper functions outside the main function:
fn convert_to_proto_snapshot(s: Snapshot) -> proto::Snapshot { proto::Snapshot { height: s.height as u64, version: s.version as u32, hash: s.hash.to_vec(), metadata: s.metadata, } } fn checkpoint_exists(s: &Snapshot) -> bool { Path::new(&s.path).exists() } pub fn list_snapshots<A, C>( app: &A, _: proto::RequestListSnapshots, ) -> Result<proto::ResponseListSnapshots, Error> where A: SnapshotManagerApplication + PlatformApplication<C>, C: CoreRPCLike, { // ... existing code ... response.snapshots = snapshots .into_iter() .filter(checkpoint_exists) .map(convert_to_proto_snapshot) .collect(); Ok(response) }packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1)
39-49: New structs for state sync version management.The implementation of
DriveAbciReducedPlatformStateStorageMethodVersionsandDriveAbciLastBlockInfoStorageMethodVersionsis appropriate, but lacks documentation comments.Consider adding Rust doc comments to enhance clarity and documentation, as recommended in previous feedback:
+/// Versioning for methods that handle reduced platform state storage #[derive(Clone, Debug, Default)] pub struct DriveAbciReducedPlatformStateStorageMethodVersions { + /// Version for the method that fetches reduced platform state pub fetch_reduced_platform_state: FeatureVersion, + /// Version for the method that stores reduced platform state pub store_reduced_platform_state: FeatureVersion, } +/// Versioning for methods that handle last block information storage #[derive(Clone, Debug, Default)] pub struct DriveAbciLastBlockInfoStorageMethodVersions { + /// Version for the method that fetches last block information pub fetch_last_block_info: FeatureVersion, + /// Version for the method that stores last block information pub store_last_block_info: FeatureVersion, }packages/rs-drive-abci/src/abci/handler/offer_snapshot.rs (2)
10-16: Assess error handling and return type.The function signature is clear and the return type is appropriate. However, consider returning more contextual errors (e.g., enumerated error variants) for debugging and telemetry purposes, especially if different snapshot-related failures must be distinguished.
17-22: Check request validation boundaries.Ensuring
app_hashhas the correct length and that the snapshot is not empty is good. Consider also verifying additional snapshot fields (e.g., format, chunk_count) if relevant, to proactively guard against malformed requests.packages/rs-drive-abci/src/abci/handler/finalize_block.rs (2)
105-115: Snapshot creation upon block finalization.Creating a snapshot after committing the block transaction is logically placed here. Consider logging or capturing metrics around snapshot creation time to monitor performance, especially if snapshots occur frequently.
120-124: Detailed tracing is beneficial.Including the
block_heightandplatform_statein the trace log is helpful for debugging. You may also want to log the result of snapshot creation for full visibility in debugging production incidents.packages/rs-drive-abci/src/abci/handler/load_snapshot_chunk.rs (3)
11-61: Validate request integrity and improve error messaging
Theload_snapshot_chunkfunction effectively retrieves and wraps snapshot chunks. However, consider verifying that:
request.chunk_idis not empty or malformed (e.g., unexpected length).- Error messages include more contextual details (e.g., chunk ID, request version) to help with troubleshooting.
Overall, the logic is cohesive, but adding these checks/refinements would enhance reliability.
63-68: CRC32 function is succinct and appropriate
This straightforward CRC32 implementation is correct for the intended usage. If performance becomes critical for large data sets, you might consider more optimized (possibly hardware-accelerated) CRC libraries.
172-197: Unit tests validate core chunk functionality
These tests confirm that serialization and deserialization match, and that tampering with data triggers failures. Adding boundary tests (e.g., empty chunk or very large chunk) might further expand coverage.packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs (1)
325-349: Load and insert WalletUtils contract during transition to version 6
The logic for loading the system data contract and inserting it is concise. It might be beneficial to ensure that the contract is validated or checked for existence before re-insertion to prevent overwriting.packages/rs-drive-abci/src/platform_types/platform_state/mod.rs (1)
226-254: Conversion logic to ReducedPlatformStateForSaving
This code checks the correct version fromstructs.reduced_platform_state_for_saving_structure_default. Logging or tracing the attempted version before returningUnknownVersionMismatchcan aid debugging. Otherwise, the branching is consistent.packages/rs-drive-abci/src/abci/config.rs (2)
66-81: Expand doc comments to clarify usage and responsibilities of each field.
Although the field descriptions are concise, consider adding details or examples about when to enable snapshots, how to choose a frequency, or how the snapshots directory is cleaned up. This will improve maintainability and encourage correct usage.
89-123: Avoid duplication across default_local, default_testnet, and default_mainnet.
All three methods return identical values, suggesting a single shared helper with environment-specific overrides. This makes it easier to maintain if any of the default values change.pub fn default_local() -> Self { - Self { - snapshots_enabled: true, - checkpoints_path: PathBuf::from("/var/lib/dash-platform/data/checkpoints"), - snapshots_frequency: 5, - max_num_snapshots: 100, - } + Self::new_defaults("/var/lib/dash-platform/data/checkpoints", true, 5, 100) } // Similarly for default_testnet and default_mainnet, // then define a `new_defaults` function that returns the struct.packages/rs-drive-abci/src/execution/engine/run_block_proposal/v1/mod.rs (2)
164-246: Ensure chain lock updates are thoroughly tested.
A significant portion of code handles verifying chain lock updates and returning specialized errors if validation fails. Always include test scenarios for invalid updates, unsynced cores, and good chain locks.Would you like me to propose a test case showing partial and complete chain lock verification successes/failures?
378-429: Log or handle potential GroveDB errors more gracefully.
While the code transforms the GroveDB error intoError::Drive(GroveDB(e)), consider logging more context for production debugging if a root hash retrieval fails (e.g., the exact cause from the underlying database).packages/rs-drive-abci/src/abci/app/check_tx.rs (2)
1-1: Document the reason for snapshot inclusion in CheckTx.
SinceCheckTxAbciApplicationtypically focuses on transaction validation, it is useful to clarify in doc comments how snapshots are relevant (e.g., for partial replay, caching, or fast sync).Also applies to: 5-5
117-133: Handle partial or missing snapshot chunks gracefully.
The newly introducedlist_snapshotsandload_snapshot_chunklikely wrap I/O or local file lookups. Consider clarifying what to do if a chunk cannot be loaded or if an unexpected offset is requested.packages/rs-drive-abci/src/abci/app/mod.rs (2)
26-30: Correct or update doc commentThe docstring states “Returns Platform,” but the method returns a
SnapshotManagerreference. Update the doc comment to remain accurate and help maintain clarity.- /// Returns Platform + /// Returns the SnapshotManager
50-57: Clarify the trait scope or rename for narrower intent
SnapshotFetchingApplicationincludes a generic reference toplatform(), which may extend beyond simple snapshot fetching. If additional non-snapshot methods are added later, consider a broader trait name or keep snapshot-focused functionality self-contained.packages/rs-drive-abci/tests/strategy_tests/state_sync.rs (3)
30-37: Consider cross-platform path handling
generate_random_pathuses string concatenation ("{}/{}{}"). On Windows, backslashes are standard. Where feasible, preferPathBuf::join()for better OS portability, if test coverage matters outside Unix-like environments.
39-51: Edge-case handling in directory I/OBoth
create_dir_if_not_existsandremove_dircan fail for reasons like permission denial or concurrent writes. Consider more robust error handling or detailed logs if these operations may involve concurrency or ephemeral environments.
71-304: Large monolithic test function
run_state_synccovers multiple steps for snapshot creation, chunk processing, and hash checks. Break it into smaller test functions or helper methods to enhance maintainability and readability. Also note thatnum_opsis derived from raw chunk length, which may not accurately reflect the count of logical operations.packages/rs-drive-abci/src/platform_types/snapshot/mod.rs (4)
1-5: Unused or incomplete referencesImports like
pin::Pinappear to be in active use, but verify all imported paths (e.g.,prost::Message, if introduced) are utilized as intended. Removing unused imports or adding clarifying doc references can improve clarity.
25-38: Document constraints for Snapshot fieldsAll snapshot fields (height, version, hash) rely on usage conventions (e.g., height >= 0). Document constraints or validate them on creation to avoid storing invalid block heights or incomplete data.
85-100: Frequency and directory creation error handlingIn
SnapshotManager::new, any I/O creation errors are just logged. If snapshots are critical, consider error propagation or fallback logic to handle unstoppable errors from filesystem (e.g., insufficient permissions or read-only filesystems).
193-229: Beware test data accumulationIntegration tests create persistent directories for snapshots. Ensure that ephemeral test directories are properly cleaned up to avoid unbounded usage of disk space, especially in continuous integration environments.
packages/rs-drive-abci/src/abci/app/full.rs (1)
39-43: **Potential directory existence check **
SnapshotManager::new()is invoked with paths fromplatform.config.state_sync_config. If creation or validation of the checkpoints path is necessary, consider adding error handling to avoid runtime failures due to invalid or inaccessible paths.let snapshot_manager = SnapshotManager::new( platform.config.state_sync_config.checkpoints_path.clone(), platform.config.state_sync_config.max_num_snapshots, platform.config.state_sync_config.snapshots_frequency, ); + // Optionally add a check if the directory exists or is writable, returning an error if notpackages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs (1)
38-156: **Comprehensive snapshot chunk application **The
apply_snapshot_chunkfunction is large but well-structured, handling:
- Chunk deserialization
- Chunk application & partial acceptance
- Final commit & Grovedb verification
Potential improvements:
- Modularity: Consider splitting out chunk deserialization/application from the final commit logic for clarity.
- Testing: Ensure thorough test coverage for partial and final chunk flows, including error conditions.
- Concurrency: The single write-lock approach is straightforward, but confirm that extended blocking won’t adversely impact other operations.
packages/rs-drive-abci/src/abci/app/consensus.rs (1)
24-36: **Lifetime documentation clarity **The comment explaining
’p: ’txstands out. Consider adding or expanding docstrings about how the'pvs'txlifetimes interplay across the consensus application. It may help future maintainers.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.lockpackages/dashmate/templates/platform/drive/tenderdash/config.toml.dotis excluded by!**/*.dot
📒 Files selected for processing (80)
.github/actions/sccache/action.yaml(1 hunks).github/workflows/release-docker-image.yml(1 hunks)Dockerfile(3 hunks)packages/dapi-grpc/Cargo.toml(1 hunks)packages/dashmate/configs/defaults/getBaseConfigFactory.js(1 hunks)packages/rs-dapi-client/Cargo.toml(1 hunks)packages/rs-dpp/src/lib.rs(1 hunks)packages/rs-dpp/src/reduced_platform_state/mod.rs(1 hunks)packages/rs-dpp/src/reduced_platform_state/v0/mod.rs(1 hunks)packages/rs-dpp/src/serialization/serialization_traits.rs(1 hunks)packages/rs-drive-abci/.env.local(1 hunks)packages/rs-drive-abci/Cargo.toml(2 hunks)packages/rs-drive-abci/src/abci/app/check_tx.rs(4 hunks)packages/rs-drive-abci/src/abci/app/consensus.rs(4 hunks)packages/rs-drive-abci/src/abci/app/full.rs(4 hunks)packages/rs-drive-abci/src/abci/app/mod.rs(3 hunks)packages/rs-drive-abci/src/abci/config.rs(2 hunks)packages/rs-drive-abci/src/abci/error.rs(1 hunks)packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs(1 hunks)packages/rs-drive-abci/src/abci/handler/finalize_block.rs(3 hunks)packages/rs-drive-abci/src/abci/handler/info.rs(1 hunks)packages/rs-drive-abci/src/abci/handler/list_snapshots.rs(1 hunks)packages/rs-drive-abci/src/abci/handler/load_snapshot_chunk.rs(1 hunks)packages/rs-drive-abci/src/abci/handler/mod.rs(1 hunks)packages/rs-drive-abci/src/abci/handler/offer_snapshot.rs(1 hunks)packages/rs-drive-abci/src/config.rs(7 hunks)packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/engine/run_block_proposal/v1/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/platform_events/core_based_updates/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_quorum_info/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_quorum_info/v0/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/platform_events/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/storage/fetch_last_block_info/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/fetch_last_block_info/v0/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/fetch_reduced_platform_state/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/fetch_reduced_platform_state/v0/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/store_last_block_info/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/store_last_block_info/v0/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/store_reduced_platform_state/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/storage/store_reduced_platform_state/v0/mod.rs(1 hunks)packages/rs-drive-abci/src/platform_types/mod.rs(1 hunks)packages/rs-drive-abci/src/platform_types/platform_state/mod.rs(4 hunks)packages/rs-drive-abci/src/platform_types/platform_state/v0/mod.rs(3 hunks)packages/rs-drive-abci/src/platform_types/snapshot/mod.rs(1 hunks)packages/rs-drive-abci/tests/strategy_tests/main.rs(1 hunks)packages/rs-drive-abci/tests/strategy_tests/state_sync.rs(1 hunks)packages/rs-drive-abci/tests/strategy_tests/voting_tests.rs(1 hunks)packages/rs-drive-proof-verifier/Cargo.toml(1 hunks)packages/rs-drive/Cargo.toml(1 hunks)packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/fetch_reduced_platform_state_bytes/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/fetch_reduced_platform_state_bytes/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/store_last_block_info_bytes/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/store_last_block_info_bytes/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/store_reduced_platform_state_bytes/mod.rs(1 hunks)packages/rs-drive/src/drive/platform_state/store_reduced_platform_state_bytes/v0/mod.rs(1 hunks)packages/rs-drive/src/error/drive.rs(1 hunks)packages/rs-json-schema-compatibility-validator/Cargo.toml(1 hunks)packages/rs-platform-version/Cargo.toml(1 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs(2 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v1.rs(2 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v2.rs(2 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v3.rs(2 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs(2 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs(2 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v6.rs(3 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_structure_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_structure_versions/v1.rs(1 hunks)packages/rs-platform-version/src/version/drive_versions/mod.rs(2 hunks)packages/rs-platform-version/src/version/drive_versions/v1.rs(2 hunks)packages/rs-platform-version/src/version/drive_versions/v2.rs(2 hunks)packages/rs-platform-version/src/version/drive_versions/v3.rs(2 hunks)packages/rs-platform-version/src/version/drive_versions/v4.rs(2 hunks)packages/rs-platform-version/src/version/mocks/v2_test.rs(2 hunks)packages/rs-platform-version/src/version/mocks/v3_test.rs(3 hunks)
🧰 Additional context used
🧠 Learnings (11)
Dockerfile (1)
Learnt from: lklimek
PR: dashpay/platform#2318
File: Dockerfile:160-198
Timestamp: 2024-11-13T10:31:31.084Z
Learning: In the `Dockerfile` for the rs-drive-abci project, when configuring sccache, we do not need to add validation checks for configuration variables, as sccache performs validation at runtime.
packages/rs-drive-abci/Cargo.toml (1)
Learnt from: shumkov
PR: dashpay/platform#2375
File: packages/rs-drive-abci/Cargo.toml:61-63
Timestamp: 2024-12-05T09:29:38.918Z
Learning: In the `drive-abci` package, avoid adding unused dependencies like `hashbrown` to `Cargo.toml`. The team relies on CI to detect dependency version issues.
packages/rs-dpp/src/reduced_platform_state/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-11-12T14:56:12.334Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
packages/rs-drive-abci/src/execution/storage/store_reduced_platform_state/v0/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-11-12T14:56:12.334Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs (1)
Learnt from: shumkov
PR: dashpay/platform#2422
File: packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs:152-163
Timestamp: 2025-01-15T08:09:59.365Z
Learning: In the `transition_to_version_8` function, errors from `grove_get_path_query` when retrieving active contested resource votes are intentionally logged and ignored (returning `Ok(())`) to allow the protocol upgrade to proceed despite query failures.
packages/rs-drive-abci/src/platform_types/platform_state/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-11-12T14:56:12.334Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
packages/rs-drive-abci/src/execution/engine/run_block_proposal/v1/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs:119-120
Timestamp: 2024-11-12T14:57:47.419Z
Learning: In the `run_block_proposal` function in `packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs`, it's acceptable to pass `platform_state` to `perform_events_on_first_block_of_protocol_change`, even if `block_platform_state` has been updated.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_structure_versions/v1.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-11-12T14:56:12.334Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
packages/rs-drive/Cargo.toml (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2431
File: packages/rs-drive/Cargo.toml:55-60
Timestamp: 2025-01-19T07:36:46.042Z
Learning: The grovedb dependencies in packages/rs-drive/Cargo.toml and related files are intentionally kept at specific revisions rather than using the latest stable version, with plans to update them at a later time.
packages/rs-drive-abci/src/platform_types/platform_state/v0/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-11-12T14:56:12.334Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1)
Learnt from: shumkov
PR: dashpay/platform#2182
File: packages/rs-platform-version/src/version/drive_abci_versions.rs:116-121
Timestamp: 2024-11-12T14:56:12.333Z
Learning: Adding Rust doc comments to structs and fields is recommended to enhance clarity and documentation.
🪛 actionlint (1.7.4)
.github/workflows/release-docker-image.yml
42-42: label "ubuntu-24.04-arm" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
🔇 Additional comments (142)
.github/actions/sccache/action.yaml (1)
37-37:✅ Verification successful
Version bump for sccache looks good.
Updating the sccache version from 0.8.2 to 0.9.1 should bring performance improvements and bug fixes to the build process.
Please ensure that CI/CD pipelines continue to function correctly with this new version. You might want to check the sccache release notes for any breaking changes:
🏁 Script executed:
#!/bin/bash # Check release notes for sccache 0.9.1 curl -s https://api.github.com/repos/mozilla/sccache/releases/tags/v0.9.1 | jq -r '.body'Length of output: 1300
sccache version bump verified and CI/CD confirmation required
The update from version 0.8.2 to 0.9.1 is confirmed to include several bug fixes and performance enhancements (such as improved jobserver handling, nvcc compilation deconstruction, and test fixes) as detailed in the release notes. There are no apparent breaking changes. Please ensure that your CI/CD pipelines continue to run smoothly with this new version.
packages/rs-drive-abci/src/platform_types/mod.rs (1)
35-36: Excellent addition for state synchronization support.Adding a snapshot module is an essential component for implementing ABCI state synchronization functionality, which aligns perfectly with the PR's purpose.
packages/rs-dpp/src/lib.rs (1)
63-63: Good addition for optimized state management.The new
reduced_platform_statemodule should help optimize state synchronization by providing a more efficient representation of the platform state for transfer operations.packages/rs-drive-abci/src/execution/mod.rs (1)
6-6: Appropriate visibility change for cross-module access.Expanding the visibility of the
platform_eventsmodule to crate-level access makes sense for the state synchronization implementation, as it likely needs to be accessed from other modules within the crate.packages/rs-json-schema-compatibility-validator/Cargo.toml (1)
10-10: Dependency version updated to be more flexibleThe change from a specific version (
1.0.115) to a more general specification ({ version = "1.0" }) provides greater flexibility for dependency updates within the 1.0.x range, which follows semantic versioning principles.packages/rs-drive-abci/tests/strategy_tests/main.rs (1)
29-29: New state_sync module added for ABCI state synchronizationThe addition of this module aligns with the "final abci state sync" feature described in the PR objectives. This is an appropriate organization of test code for the new functionality.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_structure_versions/mod.rs (1)
9-9:❓ Verification inconclusive
Added new feature version field for reduced platform state
This new field
reduced_platform_state_for_saving_structure_defaulthas been added to support state synchronization functionality. Make sure this field is properly initialized in all version constructors to avoid potentialNonevalues.
🏁 Script executed:
#!/bin/bash # Check if this new field is properly initialized in version constructors fd --type file "drive_abci_structure_versions" | grep -v "mod.rs" | xargs grep -l "DriveAbciStructureVersions" | xargs grep -A20 "reduced_platform_state_for_saving_structure_default"Length of output: 176
Ensure Field Initialization in Version Constructors
The new field
reduced_platform_state_for_saving_structure_defaultappears correctly added in the module; however, our automated search didn’t reveal any explicit initialization in the version constructors ofDriveAbciStructureVersions. Please manually verify that each constructor (or any default/macro-based initializer) properly sets a value for this field to prevent potentialNonevalues.
- File Affected:
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_structure_versions/mod.rs(line 9)- Action Required: Check all constructors or initialization logic for
DriveAbciStructureVersionsto confirm thatreduced_platform_state_for_saving_structure_defaultis assigned a default value or explicitly initialized.packages/rs-dapi-client/Cargo.toml (1)
38-38: Dependency version updated to be more flexibleThe change from a specific version (
1.0.120) to a more general specification ({ version = "1.0" }) follows the same pattern applied to other dependencies in this PR, providing greater flexibility for dependency updates within the 1.0.x range.packages/rs-drive-abci/tests/strategy_tests/voting_tests.rs (1)
1667-1668: LGTM: Helpful comment about test context.Adding this comment improves code readability by providing context about the total number of votes cast in this test scenario.
packages/rs-drive-abci/src/execution/platform_events/core_based_updates/mod.rs (1)
4-4: LGTM: Increased module visibility for internal code reuse.The visibility change from private to crate-visible (
pub(crate)) allows other parts of the crate to access the quorum info functionality while still maintaining proper encapsulation from external modules.packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_quorum_info/mod.rs (1)
1-1: LGTM: Module visibility adjustment aligns with parent module change.This change is consistent with the visibility update in the parent module, completing the visibility chain needed for proper access to quorum-related functionality throughout the crate.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_structure_versions/v1.rs (1)
7-7: New structure version for reduced platform state.The addition of
reduced_platform_state_for_saving_structure_default: 0aligns with the state sync feature implementation and correctly follows the versioning pattern used for other structure versions.packages/rs-drive-abci/.env.local (1)
16-19: Environment variables added to support state synchronization.These new environment variables properly define paths for checkpoints and the latest state file, which are essential components for the state sync feature.
packages/rs-drive-abci/src/execution/platform_events/mod.rs (1)
8-8: Visibility broadened for core_based_updates module.Changing the visibility from
pub(in crate::execution)topub(crate)makes the module accessible throughout the crate, which appears necessary for the state sync implementation.packages/dashmate/configs/defaults/getBaseConfigFactory.js (1)
312-312: Docker image tag uses feature branch name.While the image change is necessary for the state sync feature, using a feature branch name (
feat-statesync-improvements) in a Docker image tag for default configuration is not ideal for production code.Consider using a versioned tag (e.g.,
1.x.y) once the feature is merged to ensure stability and proper versioning in production environments.packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs (1)
18-18: New module addition for version 1 implementationThe addition of
mod v1;indicates a new version of the block proposal execution implementation. This aligns with the versioning pattern already established with the existingmod v0;.packages/rs-platform-version/Cargo.toml (1)
14-14:❓ Verification inconclusive
Dependency reference changed from a specific commit to a branch
The dependency
grovedb-versionhas been changed from a specific commit reference to thedevelopbranch. This might introduce instability or unpredictable behavior as the dependency will now follow the latest commit on the develop branch instead of a fixed version.
🌐 Web query:
What are the best practices for specifying Git dependencies in Cargo.toml?💡 Result:
When specifying Git dependencies in Rust's
Cargo.toml, follow these best practices to ensure stability, security, and compatibility:1. Use Explicit References for Stability
- Pin to specific commits or tags to avoid unexpected changes from upstream:
This ensures builds are reproducible[1][8]. Avoid relying solely on branches like[dependencies] my_crate = { git = "https://github.com/user/repo.git", rev = "a1b2c3d" }main, which can change over time[4][6].2. Avoid Git Dependencies for Published Crates
- Crates.io blocks packages with Git dependencies[2][8]. Use Git dependencies only for private/unpublished projects or development forks. For public packages:
- Publish dependencies to crates.io.
- Use path dependencies for local workspace crates[2][6].
3. Secure Private Repositories
- Use SSH URLs for private GitLab/GitHub repos and configure authentication:
Add a[dependencies] private_lib = { git = "ssh://git@gitlab.com/group/repo.git", branch = "dev" }.cargo/configfile to use your local Git CLI for SSH key handling[5].4. Validate Version Compatibility
- Include a
versionkey to enforce semver checks:Cargo verifies the crate's declared version matches the Git version[8].[dependencies] serde = { git = "https://github.com/serde-rs/serde", version = "1.0", branch = "main" }5. Structure Workspaces for Local Development
- Prefer path dependencies for internal crates within a monorepo:
This simplifies dependency management and avoids Git overhead for local changes[1][6].[dependencies] utils = { path = "../utils" }6. Handle Authentication in CI/CD Pipelines
- For Docker/CI environments, use SSH agent forwarding or token-based authentication:
Configure Git in your CI scripts to access private repositories securely[5].RUN --mount=type=ssh cargo build7. Enable Optional Features Correctly
- Activate features explicitly for Git-sourced crates:
Avoid assuming default features are enabled[4][8].[dependencies] reqwest = { git = "https://github.com/seanmonstar/reqwest", features = ["json"] }Comparison: Git vs. Registry Dependencies
Aspect Git Dependencies Crates.io Dependencies Publish Compatibility Blocked on crates.io[2][8] Required for publication Version Pinning Commit/tag-based SemVer ranges Offline Availability Requires cache setup Cached locally by default Security SSH/HTTPS auth needed for private Publicly accessible By following these guidelines, you balance flexibility with stability while adhering to Cargo's constraints. For published crates, transition Git dependencies to versioned crates.io entries or workspace paths before release[2][6][8].
Citations:
- 1: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/cargo/reference/specifying-dependencies.html
- 2: https://users.rust-lang.org/t/help-cargo-package-with-github-dependencies/96275
- 3: Cargo should reference git dependencies by commit hash instead of url rust-lang/cargo#7497
- 4: https://hackernoon.com/introduction-to-cargo-and-cargotoml
- 5: https://oliverjumpertz.com/blog/how-to-handle-private-gitlab-dependencies-with-cargo/
- 6: https://dev.to/alexmercedcoder/introduction-to-cargo-and-cargotoml-2l86
- 7: https://github.com/rust-lang/cargo
- 8: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
- 9: Adding a dependency from a github repository with features seems to be failing/disambiguation command is not properly parsed rust-lang/cargo#13121
- 10: https://users.rust-lang.org/t/best-practice-in-specifying-dependency-versions-in-cargo-toml/54007
Attention: Review Dependency Pinning for
grovedb-versionThe dependency in
packages/rs-platform-version/Cargo.toml(line 14) now tracks thedevelopbranch:grovedb-version = { git = "https://github.com/dashpay/grovedb", branch = "develop" }Using a branch reference rather than a fixed commit or tag can lead to unstable or unpredictable builds since any new upstream commit will be automatically included. Best practices for Cargo dependencies recommend pinning to a specific commit (using the
revkey) to ensure reproducibility and compatibility.Please verify whether this change was intentional, or if you would prefer to revert to a pinned commit for production stability.
packages/rs-drive-abci/src/execution/storage/store_reduced_platform_state/v0/mod.rs (1)
1-24: New implementation for storing reduced platform stateThis new module implements
store_reduced_platform_state_v0which serializes and stores a reduced platform state. The implementation looks sound, properly handling errors and following the project's architecture patterns.Based on the retrieved learning, it seems this is related to state serialization for version 1, though the implementation here is specifically for version 0 handling.
One suggestion is to add a brief documentation comment explaining what "reduced platform state" means in this context, as it would help future developers understand the purpose of this functionality.
packages/rs-drive-abci/src/abci/error.rs (1)
57-63: New error variants for state syncThe addition of
StateSyncBadRequestandStateSyncInternalErrorvariants provides proper error handling for the state synchronization feature being implemented in this PR. These error types appropriately distinguish between client-side bad requests and server-side internal errors.packages/dapi-grpc/Cargo.toml (1)
45-48: Dependency update and feature additionUpgrading tenderdash-proto to 1.3.0 and adding the "serde" feature is consistent with the state sync implementation requirements. The serde feature enables serialization/deserialization capabilities that are likely needed for the state synchronization functionality.
packages/rs-drive-abci/Cargo.toml (2)
52-56: Updated tenderdash-abci dependencyAppropriate upgrade of tenderdash-abci to version 1.3.0 with the necessary "crypto" and "serde" features to support the state sync implementation.
79-79: New crc dependencyThe addition of the crc crate (v3.2.1) is likely needed for checksum calculations in the state synchronization process, which is a common requirement for ensuring data integrity during state transfers.
packages/rs-drive-abci/src/execution/storage/store_reduced_platform_state/mod.rs (1)
1-32: Well-structured versioned implementation for platform state storageThe implementation follows good practices by:
- Using version-based dispatching to support backward compatibility
- Providing clear error messages when an unsupported version is encountered
- Following a modular approach with separate implementation files for each version
The code is well-documented and follows the project's error handling patterns. This structure will make it easy to add new versions in the future while maintaining backward compatibility.
packages/rs-drive-abci/src/execution/storage/mod.rs (1)
1-6: Modular structure looks goodThe addition of modules for handling reduced platform state and last block info follows a consistent naming pattern with existing modules. This modular approach aligns well with the PR objective of implementing state synchronization functionality.
packages/rs-dpp/src/reduced_platform_state/v0/mod.rs (1)
8-21: Well-structured data model for reduced platform stateThe
ReducedPlatformStateForSavingV0struct provides a clear representation of essential state data needed for synchronization. The fields are well-named and documented, and the struct properly derives the necessary traits for serialization/deserialization.packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v2.rs (1)
128-135: Version configuration looks goodThe addition of
platform_reduced_state_storageandlast_block_info_storageto the versioning structure maintains consistency with the existing pattern. Both method groups start with version 0, which is appropriate for new functionality.packages/rs-drive-abci/src/execution/storage/fetch_reduced_platform_state/mod.rs (1)
11-34: Clean implementation with proper version handlingThe implementation follows a version-based dispatch pattern with proper error handling for unknown versions. This approach maintains backward compatibility while allowing for future extensions.
packages/rs-drive/src/drive/platform_state/store_reduced_platform_state_bytes/mod.rs (1)
9-35: Implementation looks clean and follows good versioning patterns.The function uses a clean match pattern for version routing that follows the project's approach to backward compatibility. The error handling is also comprehensive, providing detailed information about version mismatches.
packages/rs-drive/src/drive/platform_state/store_last_block_info_bytes/mod.rs (1)
9-35: Implementation looks clean and follows good versioning patterns.The function follows the same versioned approach as other Drive methods, maintaining consistency in the codebase. The error handling is comprehensive with detailed mismatch information.
.github/workflows/release-docker-image.yml (1)
42-42:❓ Verification inconclusive
Verify the runner label exists in your GitHub environment.
The static analysis indicates that
ubuntu-24.04-armis not a standard GitHub-hosted runner label. If this is a custom self-hosted runner in your environment, you should either:
- Create a custom configuration file for actionlint to recognize this label, or
- Use one of the standard GitHub runner labels with appropriate setup steps for ARM builds.
🏁 Script executed:
#!/bin/bash # Check GitHub Actions runner availability in public docs echo "Checking for standard GitHub-hosted runners..." echo "Note: If 'ubuntu-24.04-arm' is a custom self-hosted runner in your environment, it won't appear in this list." echo "Standard runner labels according to GitHub documentation:" echo "- ubuntu-latest, ubuntu-24.04, ubuntu-22.04" echo "- windows-latest, windows-2022, windows-2019" echo "- macos-latest, macos-14, macos-13, etc." # Check for any self-hosted runner reference in the repo echo -e "\nChecking for self-hosted runner configuration in the repository..." grep -r "self-hosted" --include="*.yml" --include="*.yaml" .Length of output: 962
Action: Confirm and Adjust Runner Configuration
- The label
ubuntu-24.04-armis not a standard GitHub-hosted runner label (standard options include labels likeubuntu-latest,ubuntu-24.04, orubuntu-22.04).- Our grep search did not reveal any self-hosted runner configuration in the repository, which suggests that no custom runner is set up for this label.
- Please verify whether you intend to use a custom self-hosted runner. If so, consider adding a custom configuration file for actionlint so it recognizes the label. Otherwise, update the workflow to use one of the standard GitHub runner labels with the appropriate setup for ARM builds.
🧰 Tools
🪛 actionlint (1.7.4)
42-42: label "ubuntu-24.04-arm" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/mod.rs (1)
9-30: Implementation looks clean and follows good versioning patterns.The function follows the same versioned approach as other Drive methods. The error handling is also well-implemented with detailed information in case of version mismatches.
packages/rs-drive-abci/src/execution/storage/fetch_last_block_info/v0/mod.rs (1)
18-40: Implementation looks good and follows best practicesThe
fetch_last_block_info_v0method is well-implemented with proper error handling and follows Rust best practices:
- Correctly handles Drive errors by mapping them to the custom Error type
- Uses bincode for deserialization with appropriate configuration settings
- Handles corrupted serialization state with clear error messages
- Correctly uses
transpose()to convertOption<Result<T, E>>toResult<Option<T>, E>packages/rs-drive-abci/src/execution/storage/store_last_block_info/mod.rs (1)
10-31: Well-structured version-aware implementationThe
store_last_block_infomethod follows a good pattern for version-aware implementations:
- Clear documentation comment explaining the purpose
- Version checking against the platform version configuration
- Delegation to version-specific implementations
- Comprehensive error handling for unknown versions with detailed error information
packages/rs-drive/src/drive/platform_state/fetch_reduced_platform_state_bytes/v0/mod.rs (1)
8-38: Database query implementation follows best practicesThe implementation demonstrates good practices for database interaction:
- Properly constructs the query with the specific key
- Correctly uses the platform version's grove version for compatibility
- Includes proper validation of the result count
- Uses appropriate error handling for invalid query results
One minor suggestion would be to consider adding a trace or debug log statement to help with troubleshooting in case of errors or for monitoring purposes.
packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_quorum_info/v0/mod.rs (2)
24-25: Visibility change enhances code modularityThe change from private to public visibility for the
QuorumSetTypeenum improves the modularity of the codebase by allowing it to be used from other modules, which is necessary for state synchronization features.
30-30: Appropriate visibility modification for methodChanging the
quorum_typemethod visibility topub(crate)is a good design choice as it allows the method to be used within the same crate while restricting external access, maintaining proper encapsulation.packages/rs-platform-version/src/version/drive_versions/v2.rs (2)
15-20: Added new methods for reduced platform state and last block info.The imports now include two new method versions:
DriveReducedPlatformStateMethodVersionsandDriveLastBlockInfoMethodVersions, which will support new functionality related to state synchronization.
104-111: Implemented new methods for platform state sync.Two new method version structures have been added to the
DriveVersionstruct:
reduced_platform_state- For fetching and storing reduced platform statelast_block_info- For fetching and storing last block informationBoth are essential components for implementing ABCI state synchronization. The version number of 0 indicates these are newly introduced methods.
packages/rs-drive-abci/src/config.rs (4)
1-1: Added StateSyncAbciConfig import.Importing the state sync configuration from the ABCI config module to support the new state synchronization feature.
191-193: Added state sync configuration field.The
state_sync_configfield of typeStateSyncAbciConfighas been added to thePlatformConfigstruct, allowing configuration of state synchronization parameters.
285-285: Added default initialization for state sync config.When deserializing configuration, the state sync configuration is initialized with default values, ensuring backward compatibility with existing configuration files.
741-741: Added environment-specific state sync configurations.Environment-specific state sync configurations have been added for local, devnet, testnet, and mainnet environments, ensuring appropriate default settings for each network type.
Also applies to: 785-785, 870-870
packages/rs-drive-abci/src/platform_types/platform_state/v0/mod.rs (3)
33-33: Added import for ReducedPlatformStateForSavingV0.Importing the reduced platform state structure that will be used in the conversion implementation.
118-118: Enhanced Debug implementation.Updated the Debug implementation to include the
previous_fee_versionsfield, improving observability and debugging capabilities.
257-278: Implemented TryFrom for creating reduced platform state.Added a conversion implementation from
PlatformStateV0toReducedPlatformStateForSavingV0, extracting only the essential fields needed for state synchronization:
- protocol versions
- validator set quorum hashes
- previous fee versions
This approach optimizes state transfer by reducing the data size while maintaining the critical information needed for synchronization.
packages/rs-drive-abci/src/execution/storage/fetch_reduced_platform_state/v0/mod.rs (2)
1-15: Added imports for reduced platform state functionality.The imports include error handling, Drive access, serialization utilities, and the reduced platform state structures necessary for implementing the fetch functionality.
16-42: Implemented reduced platform state fetching.This method fetches the reduced platform state from the Drive storage and deserializes it. Key features:
- Proper error handling with appropriate mapping to domain errors
- Version-aware deserialization using the platform version
- Detailed error logging with hex-encoded bytes for debugging
- Clean result handling with
transpose()to maintain the Option wrapperThe implementation follows good practices for error handling and logging, which will be valuable during troubleshooting of state synchronization issues.
packages/rs-drive/src/drive/platform_state/store_last_block_info_bytes/v0/mod.rs (1)
16-26:❓ Verification inconclusive
Double check error handling pattern
The
.unwrap().map_err()pattern on lines 25-26 is unusual. Typically,unwrap()would panic on error, not allowingmap_err()to execute. Please verify if this is the intended behavior for GroveDB's error handling or if it should be replaced with a pattern like.map_err(Error::GroveDB)?.
🏁 Script executed:
#!/bin/bash # Check for similar error handling patterns in the codebase rg "unwrap\(\)\.map_err" --type rustLength of output: 38
Action: Verify Error Handling Chain in GroveDB Insert Operation
At
packages/rs-drive/src/drive/platform_state/store_last_block_info_bytes/v0/mod.rs(lines 16-26), we see the following chain:self.grove .insert( &misc_path(), LAST_BLOCK_INFO_KEY, Element::Item(last_block_info_bytes.to_vec(), None), Some(InsertOptions::default()), transaction, &platform_version.drive.grove_version, ) .unwrap() .map_err(Error::GroveDB)?;This pattern—calling
.unwrap()immediately before.map_err(Error::GroveDB)?—is unconventional becauseunwrap()will panic on error, thus preventing the subsequent error mapping from ever executing.
- Action Required: Please verify whether
self.grove.insert(...)returns a nestedResultwhere an outerResultmust be unwrapped to access an inner result that still needs error mapping.- Suggestion: If the intention is only to propagate errors without panicking, consider replacing
.unwrap().map_err(Error::GroveDB)?with a single.map_err(Error::GroveDB)?call.packages/rs-drive/src/drive/platform_state/fetch_reduced_platform_state_bytes/mod.rs (1)
1-30: Well-structured versioned method implementationThis module implements a versioned approach to fetch reduced platform state bytes, which is good for backward compatibility and future extensibility. The implementation includes proper error handling for unsupported versions and follows a clean pattern of delegating to version-specific implementations.
A few observations:
- The code correctly uses the platform version to determine which implementation to use
- Error handling for unsupported versions is comprehensive and informative
- The documentation comments are helpful but could be expanded to describe the return value structure
packages/rs-drive-abci/src/execution/storage/fetch_last_block_info/mod.rs (1)
25-25:✅ Verification successful
Confirm implementation of
fetch_last_block_info_v0existsEnsure that the
fetch_last_block_info_v0static method referenced here exists in the v0 module and has a matching signature.
🏁 Script executed:
#!/bin/bash # Check if the fetch_last_block_info_v0 function exists in the v0 module grep -r "fn fetch_last_block_info_v0" packages/rs-drive-abci/src/execution/storage/fetch_last_block_info/v0/Length of output: 231
Verification Successful: Implementation Confirmed
The
fetch_last_block_info_v0function is present in thepackages/rs-drive-abci/src/execution/storage/fetch_last_block_info/v0/mod.rsfile with the expected visibility and signature. No further changes are needed.packages/rs-drive-proof-verifier/Cargo.toml (2)
37-40: Version and feature update for tenderdash-abciThe dependency on tenderdash-abci has been updated from 1.2.1 to 1.3.0, and the "serde" feature has been added. This aligns with the ABCI state sync feature implementation, enabling proper serialization and deserialization for state sync data structures.
43-43: Changed serde_json version to major version onlyThe version requirement for serde_json has been changed from a specific patch version (1.0.103) to just the major version (1.0). This allows more flexibility with dependency resolution while maintaining compatibility.
packages/rs-dpp/src/serialization/serialization_traits.rs (2)
34-37: New reduced serialization trait addedThe
ReducedPlatformSerializabletrait introduces a mechanism for creating more compact serialized representations of platform state, which is essential for efficient state synchronization between nodes.
39-46: Added complementary deserialization trait for reduced stateThe
ReducedPlatformDeserializabletrait complements the serialization trait, providing version-aware deserialization for reduced platform state. This is important for maintaining compatibility across different versions during state sync operations.packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs (2)
9-9: Added new method version imports for state sync functionalityNew imports for
DriveAbciLastBlockInfoStorageMethodVersionsandDriveAbciReducedPlatformStateStorageMethodVersionssupport the state sync feature implementation.Also applies to: 12-12
131-138: Added method versions for state sync operationsTwo new method version groups have been added:
platform_reduced_state_storagefor handling the reduced platform statelast_block_info_storagefor tracking last block informationBoth are essential components for implementing ABCI state synchronization functionality, with initial method versions set to 0.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v1.rs (2)
9-9: Added imports for state sync method versionsImported the same method version structs as in v5.rs to support state sync functionality in earlier platform versions.
Also applies to: 12-12
127-134: Backported state sync method versions to v1The same method version groups added to v5 have been added to v1:
platform_reduced_state_storagelast_block_info_storageThis ensures consistent implementation of state sync functionality across all platform versions.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v3.rs (2)
9-9: Consistent import additionsThese imports align with the new methods being added to the
DRIVE_ABCI_METHOD_VERSIONS_V3constant.Also applies to: 12-12
127-134: New platform state storage methods for state syncThe addition of
platform_reduced_state_storageandlast_block_info_storagewith initial version 0 is appropriate for new functionality. These components will enable the ABCI state sync feature by providing methods to store and retrieve reduced platform state and last block information.packages/rs-drive/src/drive/platform_state/mod.rs (2)
1-1: New modules for state sync functionalityThese module declarations introduce the implementation for fetching and storing reduced platform state and last block information, which are essential components for the ABCI state sync feature.
Also applies to: 3-4, 6-6
9-10: Constants for storage keysThe constants
REDUCED_PLATFORM_STATE_KEYandLAST_BLOCK_INFO_KEYprovide clear, descriptive names for the storage keys used in the state sync implementation. The byte array values are appropriate and follow the existing naming pattern.packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs (2)
9-9: Consistent import additions across versionsThe imports align with the new methods being added, ensuring consistency across different version files.
Also applies to: 12-12
127-134: Maintaining consistency across version filesThe addition of the same state sync components to
DRIVE_ABCI_METHOD_VERSIONS_V4as were added to V3 ensures a consistent implementation across different protocol versions.Dockerfile (4)
169-169: Update sccache versionUpdating
SCCHACHE_VERSIONfrom 0.8.2 to 0.9.1 ensures consistency with the changes in GitHub Actions workflows.
575-575: New environment variable for checkpointsThe addition of
CHECKPOINTS_PATHprovides a dedicated location for state sync checkpoints.
602-605: Update permissions for new directory structureCorrectly updating the ownership of all required directories, including the new checkpoint path, to the dash user ensures proper permission management.
585-591:✅ Verification successful
Ensure required paths exist
Creating the necessary directories including the new
CHECKPOINTS_PATHensures the application has the proper structure on startup.Note the TODO comment about removing the duplicate path when drive-abci is fixed, which should be addressed in future updates.
🏁 Script executed:
#!/bin/bash # Check if this TODO is mentioned in any issues or other PRs echo "Searching for related TODO mentions in the codebase..." rg "remove /var/lib/dash-platform/data/checkpoints" -A 2 -B 2Length of output: 704
Review Verification – Dockerfile Directory Setup
The Dockerfile correctly creates all necessary directories, including the addition ofCHECKPOINTS_PATH. The TODO comment about removing/var/lib/dash-platform/data/checkpointswhen drive-abci is fixed appears in multiple locations (as confirmed by the search result), so it’s clear the duplicate path removal is pending future fixes.No changes are required at this time since the code meets current expectations.
packages/rs-platform-version/src/version/drive_versions/v3.rs (2)
15-20: Updated imports to support new state functionality.The imports have been properly extended to include the new
DriveLastBlockInfoMethodVersionsandDriveReducedPlatformStateMethodVersionstypes which are essential for the ABCI state synchronization feature.
104-111: New methods for state synchronization support added.The
reduced_platform_stateandlast_block_infofields have been properly added to theDriveMethodVersionsstructure with appropriate versioning. This enables two key functionalities:
- Ability to store and fetch reduced platform state (likely for more efficient state synchronization)
- Ability to store and fetch last block information (necessary for proper state synchronization between nodes)
Both are initialized with version 0, following the pattern for newly introduced methods.
packages/rs-platform-version/src/version/drive_versions/mod.rs (3)
63-64: Public API extension for reduced state and block info.New fields have been properly added to the
DriveMethodVersionsstruct, following the existing pattern. These additions maintain backward compatibility while extending the functionality.
73-77: New struct for reduced platform state operations.The
DriveReducedPlatformStateMethodVersionsstruct is correctly defined with appropriate fields for fetching and storing reduced platform state. This structure follows the established pattern in the codebase for method versioning.
79-83: New struct for last block info operations.The
DriveLastBlockInfoMethodVersionsstruct is properly defined with methods for fetching and storing last block information. These operations are essential for state synchronization between nodes.packages/rs-platform-version/src/version/mocks/v2_test.rs (2)
42-47: Updated imports for test consistency.The import section has been properly updated to include the new method version types, ensuring that the test code can reference these new structures.
140-147: Test fixture updated with new method versions.The test platform configuration has been correctly updated to include the new method versions, ensuring that the test environment matches the production environment. Both new structures are initialized with version 0, maintaining consistency with their production counterparts.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v6.rs (3)
9-12: Added imports for new ABCI method version types.The imports have been properly updated to include the new ABCI method version types for last block information and reduced platform state storage.
128-135: Added new ABCI method versions for state synchronization.Two new method version structures have been correctly added to the
DRIVE_ABCI_METHOD_VERSIONS_V6constant:
platform_reduced_state_storage- For handling reduced platform state operationslast_block_info_storage- For managing last block informationBoth are initialized with version 0, indicating they are newly introduced methods. These additions complete the state synchronization feature across the ABCI layer.
22-22:✅ Verification successful
Version increment for run_block_proposal method.
The version of the
run_block_proposalmethod has been incremented from 0 to 1, indicating a change in functionality. This is likely related to the addition of state synchronization features.
🏁 Script executed:
#!/bin/bash # Search for the implementation of run_block_proposal to understand what changed rg -A 5 "fn run_block_proposal" --type rustLength of output: 1976
Attention: Verified Version Bump for
run_block_proposalThe version mapping in
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v6.rsnow correctly setsrun_block_proposal: 1. This update aligns with the existence of a dedicated implementation inpackages/rs-drive-abci/src/execution/engine/run_block_proposal/v1/mod.rs, confirming that the functionality has indeed been revised—likely to support state synchronization enhancements.
- Confirmed the presence of both
run_block_proposal_v0andrun_block_proposal_v1implementations in the codebase.- The update in the platform version file now directs to the new functionality provided in the v1 implementation.
packages/rs-drive-abci/src/abci/handler/mod.rs (2)
46-48: Additions of new snapshot modules aligned with state sync functionality.The additions of modules
list_snapshots,load_snapshot_chunk, andoffer_snapshotimplement core functionality required for ABCI state synchronization.
60-62: Exported public functions for snapshot operations.These public exports make the snapshot handling functions accessible to other modules, which is necessary for proper state synchronization implementation.
packages/rs-platform-version/src/version/drive_versions/v4.rs (2)
15-20: New imports for state sync functionality.The added imports for
DriveLastBlockInfoMethodVersionsandDriveReducedPlatformStateMethodVersionsproperly prepare the file for the new structs being used.
104-111: Added version support for reduced platform state and last block info.These additions extend the versioning system to support the new state synchronization features. Both method groups are initialized with version 0, which is appropriate for new functionality.
packages/rs-platform-version/src/version/mocks/v3_test.rs (3)
25-28: New imports for test mocks.The imported method version structures ensure that the test mocks can properly incorporate the new state sync functionality.
161-168: Added state sync method versions to test mock.The test mock now correctly includes the new reduced platform state and last block info storage methods, ensuring tests will properly validate the new functionality.
55-55:✅ Verification successful
Updated run_block_proposal version.
The version update from 0 to 1 indicates changes to the block proposal functionality, which is likely related to the state sync implementation.
🏁 Script executed:
#!/bin/bash # Search for the implementation of the run_block_proposal function to understand its changes rg -A 5 -B 5 "fn run_block_proposal" --type rustLength of output: 3766
Attention: Updated run_block_proposal version confirmed
The update in the mock (from 0 to 1) correctly reflects the introduction of the v1 implementation of
run_block_proposal(as seen in packages/rs-drive-abci/src/execution/engine/run_block_proposal/v1/mod.rs), and aligns with the revised block proposal and state sync functionality.
- The test mock in
packages/rs-platform-version/src/version/mocks/v3_test.rsnow accurately indicates the new version.- The change is consistent with the refactored implementation across the codebase.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1)
29-30: New fields for state sync in DriveAbciMethodVersions.These additions properly integrate the new state synchronization capabilities into the versioning system.
packages/rs-platform-version/src/version/drive_versions/v1.rs (3)
15-20: Imports and method versions look consistent.No issues are apparent in the newly added method version imports. They follow the existing pattern, and the references are correct.
104-107: Ensure test coverage for newly introducedreduced_platform_statemethod versions.While adding these version references is valid, it’s recommended to verify that corresponding logic and unit tests exist (or are planned) to confirm that fetching and storing reduced platform state works as intended.
108-111: Confirm usage oflast_block_infoversion references.Similarly, confirm that
fetch_last_block_info_bytesandstore_last_block_info_bytesare fully tested and used. Lack of explicit invocation could lead to future code drift or untested features.packages/rs-drive-abci/src/abci/handler/offer_snapshot.rs (2)
32-63: Wipe and re-initialize logic looks correct.The flow for wiping GroveDB and starting a new snapshot syncing session is logically sound. Confirm that external references or caches to the freshly wiped database are properly reset to avoid stale references elsewhere in the code.
64-102: Validate height comparison and session re-initialization.Rejecting snapshots with heights less than or equal to the current session is sensible. Just ensure the user or system is aware of how multiple snapshot offers at different heights are orchestrated and that older snapshots will not cause erroneous rewinds.
packages/rs-drive-abci/src/abci/handler/finalize_block.rs (4)
1-4: Snapshot management trait import approved.Adding
SnapshotManagerApplicationto the imports is appropriate for the new snapshot feature. Good job maintaining modular design.
20-23: Expanded trait constraints are valid.Requiring the application to implement
SnapshotManagerApplicationensures that snapshot operations can be orchestrated here. This follows best practices for strengthening type guarantees.
103-104: Relaxed atomic storage seems acceptable.Storing the block height with
Ordering::Relaxedmight be sufficient for reading and writing in a single-threaded or lock-protected context. Ensure you have no concurrency requirements (e.g., cross-thread visibility) that warrant stronger ordering.
116-119: Potential race condition in state loading.After committing the block and creating a snapshot, the state is reloaded. If other asynchronous writes or reads occur, verify that the reloaded state is accurate and consistent for subsequent logic.
packages/rs-drive-abci/src/abci/handler/load_snapshot_chunk.rs (3)
1-10: Imports are well-structured and relevant
No issues are found with the selected imports. They match the functionalities used in this file (bincode, grove, dpp, etc.) and adhere to common Rust patterns.
70-84: ChunkData struct is well-defined
The fields—version, crc32, size, and chunk—are clear and serve their respective purposes. Documenting any versioning strategy (e.g., how CHUNK_VERSION changes in future updates) would help maintainers.
85-169: Thorough metadata handling in ChunkData methods
serializeproperly encodes data and logs errors.verifyfully checks version, size, and CRC to ensure integrity.deserializeintegrates the verification step to guarantee consistency before returning the object.This robust approach prevents corrupted or mismatched chunks from propagating.
packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs (2)
24-27: Imports for specialized balances
These newly added imports enable refactoring specialized balances functionality. They appear well-organized and are referenced properly below. No issues noted.
231-323: Initialize withdrawal structures during transition to protocol version 4
This function properly creates the sum tree and broadcasted transactions subtree if missing, and updates masternode owner keys. Consider verifying:
- That newly inserted keys do not collide with existing keys, especially if concurrency is possible.
- Whether partial key updates can leave the identity in an inconsistent state.
Otherwise, the code appears logically consistent and follows a clear, stepwise approach.
packages/rs-drive-abci/src/platform_types/platform_state/mod.rs (3)
18-20: New serialization imports introduced
The import of additional serialization traits (PlatformDeserializableFromVersionedStructure, PlatformSerializable, ReducedPlatformSerializable) aligns with the newly introduced extended or reduced serialization steps below. This usage is consistent.
32-33: Importing ReducedPlatformStateForSaving
The new references toReducedPlatformStateForSavingtypes facilitate more compact saving of platform state data. Ensure that the underlying logic for partial serialization remains parallel to the full version to avoid diverging states.
71-88: ReducedPlatformSerializable trait implementation
Implementingreduced_serialize_to_bytesis a clean addition, reusing standard bincode configuration. The error handling is consistent with the rest of the code. This improves code reuse for partial platform state outputs.packages/rs-drive-abci/src/abci/config.rs (2)
5-5: Use consistent import sorting or grouping if required by your style guide.
Currently,std::path::PathBufis introduced here. If your project enforces any particular grouping convention (e.g., standard library imports first), ensure that it aligns with the rest of the file.
83-87: Confirm the default environment is the correct fallback.
TheDefaultimplementation defers todefault_mainnet(). Verify that new local/test/staging environments won't unintentionally inherit the mainnet configuration.packages/rs-drive-abci/src/execution/engine/run_block_proposal/v1/mod.rs (2)
88-98: Check for consistent version negotiation logic.
The code checks whether the proposal’sconsensus_versions.appmatchesplatform_version.protocol_versiononly ifknown_from_usis false. Confirm that local or same-host proposals also need the same protocol version enforcement.
321-331: Validate concurrency impacts for large numbers of state transitions.
Ifraw_state_transitionscan become large, ensure that higher-level concurrency or memory usage is properly handled. Also consider adding performance tests or monitoring for potential bottlenecks in production.packages/rs-drive-abci/src/abci/app/check_tx.rs (3)
26-27: Confirm snapshot_manager initialization within CheckTx usage.
Ensure that the snapshot manager required byCheckTxAbciApplicationis fully needed during the check-tx phase. If this field will see minimal usage here, factor it into a smaller or more relevant context.
39-46: SnapshotManagerApplication trait usage is well-structured.
The approach of returning a reference tosnapshot_manager()is consistent and likely meets the trait’s requirements with minimal overhead.
53-64: Revisit max_num_snapshots and snapshots_frequency for test and local usage.
Although values are driven fromplatform.config.state_sync_config, confirm they are practical for performance duringcheck_tx.packages/rs-drive-abci/src/abci/app/mod.rs (2)
13-13: Ensure consistent error handling around snapshotsThe newly introduced imports for
SnapshotFetchingSessionandSnapshotManagersuggest additional snapshot-based workflows. Verify that all methods triggering or interacting with these types handle snapshot-related failures consistently, especially in downstream code.
33-39: Transaction lifetime parameter changesSwitching from
'ato'prefines lifetime scoping for transactions. Confirm that this change is reflected in all trait implementors, ensuring there are no mismatched lifetimes or leftover references to'a.packages/rs-drive-abci/tests/strategy_tests/state_sync.rs (2)
1-29: Validate module boundaryAdding a dedicated test module is good practice for grouping state sync tests. Ensure no concurrency issues arise if other test modules also manipulate the same network or file paths.
53-69: Potential infinite loop
get_target_folder()repeatedly pops directories until aCargo.lockis found. In rare cases, if missing, this could become an infinite loop at root. Consider a safety check or fallback to avoid that scenario.packages/rs-drive/Cargo.toml (1)
55-60: Pinning vs. branch referencesUsing
branch = "develop"for multiplegrovedbcrates may introduce version uncertainty. If a specific commit is needed for stability or reproducible builds, pin to a commit or tag. Otherwise, confirm that referencing a moving branch won’t cause unexpected dependency breaks.packages/rs-drive-abci/src/platform_types/snapshot/mod.rs (2)
21-23: CHUNK_SIZE_16MB is not referencedIf intended as a boundary for snapshot chunks, ensure it is enforced somewhere in the I/O path or remove unnecessary constants. Unused constants can cause confusion.
139-141: Skipping on non-multiple frequencies
if height == 0 || height % self.freq != 0 { return Ok(()); }effectively ignores all heights that aren’t multiples. Confirm this meets your sync strategy requirements (e.g., skipping block 1 with freq=2). Overlooking certain blocks might hamper debugging or replay scenarios.packages/rs-drive-abci/src/abci/app/full.rs (10)
1-3: **Clean integration of Snapshot traits **All newly introduced traits (
SnapshotFetchingApplication,SnapshotManagerApplication, etc.) are neatly imported and appear consistent with your design. No issues detected with these additions.
11-11: **Snapshot modules import looks good **Importing
SnapshotFetchingSessionandSnapshotManagerhere is straightforward and aligns with the newly introduced functionality.
30-33: **Concurrent data structures are acceptable, but verify thread safety **Storing the
snapshot_fetching_sessionunder anRwLock<Option<SnapshotFetchingSession<'a>>>looks sound for concurrency. However, ifsnapshot_manageralso needs concurrent access (reads/writes from different threads), consider placing it under a lock or confirming that its operations are already thread-safe.
48-49: **Initialization looks standard **Using
Default::default()forsnapshot_fetching_sessionand assigningsnapshot_manageris a typical, concise approach. No issues here.
60-64: **SnapshotManagerApplication trait implementation is concise **The method simply returns the
snapshot_manager. This is well-aligned with the trait’s contract and appears correct.
66-74: **SnapshotFetchingApplication implementation is consistent **Returning a reference to the
snapshot_fetching_sessionlock and platform is coherent. The lifetime usage in this context seems correct.
185-190: **Snapshot offering handler invocation **Delegating
offer_snapshotto thehandler::offer_snapshotfunction is succinct and clear. Ensure that the handler function has comprehensive validation and logging for incoming workflow segments.
192-197: **Snapshot chunk application handler **Forwarding
apply_snapshot_chunkto the handler is well-structured. It’s good that error mapping propagates any internal issues up as exceptions.
199-204: **Snapshot listing logic **Similarly, delegating to
handler::list_snapshotsis straightforward. Looks good.
206-211: **Loading snapshot chunks **Invoking
handler::load_snapshot_chunkis consistent with the snapshot functionality introduced above. Implementation is concise and aligned with the existing pattern.packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs (4)
1-37: **Imports reviewed, all appear relevant **All newly added imports (e.g.,
ChunkData,ExtendedQuorumListResult, etc.) look necessary for snapshot chunk processing and platform state reconstruction.
269-305: **Hard-coded parameter forget_protx_diff_with_masternodes**Using
Some(1)as the base block height may be intended, but might also be incidental:.get_protx_diff_with_masternodes(Some(1), core_block_height)?;Double-check if this is the desired behavior or a placeholder. If it’s a placeholder, expose it as a configurable parameter or document its usage.
307-357: **Quorum verification set construction **Fetching quorums and building
VerificationQuorumobjects is performed cleanly. Error handling for missing quorums is appropriate. This logic is robust.
359-436: **Validator list assembly appears solid **Collecting validator sets, sorting them by core height (with a tie-break on hash), and appending them to the platform state is well-organized. No immediate improvements needed aside from ensuring thorough testing of edge cases.
packages/rs-drive-abci/src/abci/app/consensus.rs (11)
1-4: **Imports for application traits **Bringing in
BlockExecutionApplication,PlatformApplication, etc. is consistent with howFullAbciApplicationwas handled. No issues noted.
11-11: **Snapshot modules import validated **Adding
SnapshotFetchingSessionandSnapshotManagerinto scope aligns with the new state sync logic.
13-13: **GRPC integration note **The
use dapi_grpc::tonic;import might hint at possible expansions for gRPC-based calls. No problems here.
38-53: **Snapshot manager initialization **Similar pattern to
FullAbciApplication—the snapshot manager is correctly instantiated from config. Straightforward and consistent.
56-60: **PlatformApplication trait alignment **Returning a reference to the underlying
platformis consistent with the trait definition.
62-66: **SnapshotManagerApplication trait alignment **The method simply exposes
snapshot_manager. No issues.
68-76: **SnapshotFetchingApplication trait usage **Declaration is identical to
FullAbciApplication, returning theRwLocksession plus aplatformreference. Looks good.
78-82: **BlockExecutionApplication trait usage **No special differences from other apps. The concurrency pattern with
block_execution_contextremains consistent.
84-111: **TransactionalApplication logic is standard **Starting and committing transactions is consistent with the approach used in
FullAbciApplication. No anomalies.
113-117: **Debug trait for easy inspection **Implementing
Debugwith a simple placeholder is typical and helpful for debugging. No concerns.
119-199: **New snapshot ABCI methods **Adding
offer_snapshotandapply_snapshot_chunkfosters snapshot management in consensus mode. Implementation defers to handler functions, matching the approach inFullAbciApplication.
packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/v0/mod.rs
Outdated
Show resolved
Hide resolved
| use crate::drive::platform_state::REDUCED_PLATFORM_STATE_KEY; | ||
| use crate::drive::system::misc_path; | ||
| use crate::drive::Drive; | ||
| use crate::error::Error; | ||
| use grovedb::operations::insert::InsertOptions; | ||
| use grovedb::{Element, TransactionArg}; | ||
| use platform_version::version::PlatformVersion; | ||
|
|
||
| impl Drive { | ||
| pub(super) fn store_reduced_platform_state_bytes_v0( | ||
| &self, | ||
| reduced_state_bytes: &[u8], | ||
| transaction: TransactionArg, | ||
| platform_version: &PlatformVersion, | ||
| ) -> Result<(), Error> { | ||
| self.grove | ||
| .insert( | ||
| &misc_path(), | ||
| REDUCED_PLATFORM_STATE_KEY, | ||
| Element::Item(reduced_state_bytes.to_vec(), None), | ||
| Some(InsertOptions::default()), | ||
| transaction, | ||
| &platform_version.drive.grove_version, | ||
| ) | ||
| .unwrap() | ||
| .map_err(Error::GroveDB)?; | ||
| Ok(()) | ||
| } | ||
| } |
There was a problem hiding this comment.
Potential error handling issue with .unwrap()
The implementation for storing reduced platform state bytes has an error handling concern. The use of .unwrap() at line 25 could cause a panic if the operation returns None instead of Ok/Err.
- .unwrap()
- .map_err(Error::GroveDB)?;
+ .map_err(Error::GroveDB)?;This removes the unnecessary unwrap that could potentially cause runtime panics. The GroveDB insert method should return a Result type directly, so there's no need to call unwrap() before map_err().
Additionally, consider adding more detailed documentation explaining what conditions might cause this operation to fail.
📝 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.
| use crate::drive::platform_state::REDUCED_PLATFORM_STATE_KEY; | |
| use crate::drive::system::misc_path; | |
| use crate::drive::Drive; | |
| use crate::error::Error; | |
| use grovedb::operations::insert::InsertOptions; | |
| use grovedb::{Element, TransactionArg}; | |
| use platform_version::version::PlatformVersion; | |
| impl Drive { | |
| pub(super) fn store_reduced_platform_state_bytes_v0( | |
| &self, | |
| reduced_state_bytes: &[u8], | |
| transaction: TransactionArg, | |
| platform_version: &PlatformVersion, | |
| ) -> Result<(), Error> { | |
| self.grove | |
| .insert( | |
| &misc_path(), | |
| REDUCED_PLATFORM_STATE_KEY, | |
| Element::Item(reduced_state_bytes.to_vec(), None), | |
| Some(InsertOptions::default()), | |
| transaction, | |
| &platform_version.drive.grove_version, | |
| ) | |
| .unwrap() | |
| .map_err(Error::GroveDB)?; | |
| Ok(()) | |
| } | |
| } | |
| use crate::drive::platform_state::REDUCED_PLATFORM_STATE_KEY; | |
| use crate::drive::system::misc_path; | |
| use crate::drive::Drive; | |
| use crate::error::Error; | |
| use grovedb::operations::insert::InsertOptions; | |
| use grovedb::{Element, TransactionArg}; | |
| use platform_version::version::PlatformVersion; | |
| impl Drive { | |
| pub(super) fn store_reduced_platform_state_bytes_v0( | |
| &self, | |
| reduced_state_bytes: &[u8], | |
| transaction: TransactionArg, | |
| platform_version: &PlatformVersion, | |
| ) -> Result<(), Error> { | |
| self.grove | |
| .insert( | |
| &misc_path(), | |
| REDUCED_PLATFORM_STATE_KEY, | |
| Element::Item(reduced_state_bytes.to_vec(), None), | |
| Some(InsertOptions::default()), | |
| transaction, | |
| &platform_version.drive.grove_version, | |
| ) | |
| .map_err(Error::GroveDB)?; | |
| Ok(()) | |
| } | |
| } |
There was a problem hiding this comment.
This unwraps the cost. So there is not failure on this.
There was a problem hiding this comment.
@ogabrielides Thanks for clarifying! I understand now that the .unwrap() is intentionally unwrapping the cost value returned by the GroveDB operation, not handling a potential error case. I'll make note of this pattern for future reviews.
✏️ Learnings added
Learnt from: ogabrielides
PR: dashpay/platform#2486
File: packages/rs-drive/src/drive/platform_state/store_reduced_platform_state_bytes/v0/mod.rs:1-29
Timestamp: 2025-03-07T12:37:44.257Z
Learning: GroveDB operations like `insert()` return a tuple that includes a cost value which needs to be unwrapped with `.unwrap()` before error handling with `.map_err()`.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
packages/rs-drive-abci/src/execution/storage/fetch_last_block_info/mod.rs
Show resolved
Hide resolved
packages/rs-drive-abci/src/execution/engine/run_block_proposal/v1/mod.rs
Show resolved
Hide resolved
packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
Dockerfile (3)
176-176: Check Argument Naming Consistency for sccache VersionThe updated argument
ARG SCCHACHE_VERSION=0.9.1correctly upgrades the sccache version. However, note the spelling “SCCHACHE_VERSION” whereas the common convention is “SCCACHE_VERSION”. Please verify that this naming is intentional and consistent across related configurations.
597-603: Ensure Directory Creation with a TODO ReminderThe
RUN mkdir -p ...command now creates all the required directories—including/var/log/dash,${DB_PATH},${CHECKPOINTS_PATH},${REJECTIONS_PATH}, and/var/lib/dash-platform/data/checkpoints. The TODO note indicates that/var/lib/dash-platform/data/checkpointsshould be removed once drive-abci is fixed. Please ensure that this workaround is tracked and eventually resolved in your issue management process.
614-617: User Creation and Ownership UpdateThe commands for adding the user and updating directory ownership now include
/var/lib/dash-platform/data/checkpoints(as noted in the TODO). Confirm that including this path in the ownership change aligns with the deployment strategy and that the pending removal of this directory is addressed in a future fix.packages/rs-drive-abci/src/platform_types/platform_state/mod.rs (1)
71-87: Well-structured implementation of ReducedPlatformSerializableThe implementation follows the same pattern as the existing
PlatformSerializabletrait, providing a clean way to serialize the platform state in a reduced format.Consider adding documentation explaining when reduced serialization should be used versus full serialization, which would improve maintainability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (10)
Dockerfile(3 hunks)packages/dapi-grpc/Cargo.toml(1 hunks)packages/rs-dapi-client/Cargo.toml(1 hunks)packages/rs-dpp/src/lib.rs(1 hunks)packages/rs-drive-abci/Cargo.toml(2 hunks)packages/rs-drive-abci/src/platform_types/platform_state/mod.rs(4 hunks)packages/rs-drive-abci/src/platform_types/platform_state/v0/mod.rs(3 hunks)packages/rs-drive-abci/tests/strategy_tests/main.rs(1 hunks)packages/rs-drive-proof-verifier/Cargo.toml(1 hunks)packages/rs-drive/Cargo.toml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (7)
- packages/rs-dpp/src/lib.rs
- packages/rs-dapi-client/Cargo.toml
- packages/rs-drive-abci/tests/strategy_tests/main.rs
- packages/rs-drive-abci/src/platform_types/platform_state/v0/mod.rs
- packages/rs-drive-proof-verifier/Cargo.toml
- packages/rs-drive-abci/Cargo.toml
- packages/rs-drive/Cargo.toml
🧰 Additional context used
🧠 Learnings (2)
Dockerfile (1)
Learnt from: lklimek
PR: dashpay/platform#2318
File: Dockerfile:160-198
Timestamp: 2024-11-13T10:31:31.084Z
Learning: In the `Dockerfile` for the rs-drive-abci project, when configuring sccache, we do not need to add validation checks for configuration variables, as sccache performs validation at runtime.
packages/rs-drive-abci/src/platform_types/platform_state/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-11-12T14:56:12.334Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
⏰ Context from checks skipped due to timeout of 90000ms (16)
- GitHub Check: Rust packages (rs-dapi-client) / Tests
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (rs-dapi-client) / Linting
- GitHub Check: Rust packages (json-schema-compatibility-validator) / Linting
- GitHub Check: Rust packages (drive-abci) / Unused dependencies
- GitHub Check: Rust packages (dash-sdk) / Unused dependencies
- GitHub Check: Rust packages (dapi-grpc) / Formatting
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (drive) / Unused dependencies
- GitHub Check: Rust packages (dapi-grpc) / Unused dependencies
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Rust crates security audit
🔇 Additional comments (4)
Dockerfile (1)
587-587: New Checkpoints Path Environment VariableThe addition of
ENV CHECKPOINTS_PATH=/var/lib/dash/rs-drive-abci/db-checkpointsimproves the clarity for managing database checkpoints in the Drive ABCI setup. Ensure that the application components reference this variable appropriately.packages/rs-drive-abci/src/platform_types/platform_state/mod.rs (2)
17-19: Import changes look goodThe new imports for
ReducedPlatformSerializableproperly support the state sync functionality being added.
32-33: Import for reduced platform state types are properly addedThese imports correctly reference the new reduced platform state types that will be used for state synchronization.
packages/dapi-grpc/Cargo.toml (1)
34-48:✅ Verification successful
Resolve Duplicate Dependency Definitions for
tenderdash-protoIt appears that
tenderdash-protois defined twice in the[dependencies]section—once at line 34 and then again at lines 45–48 with additional features. TOML does not support duplicate keys in the same table, which may lead to unexpected behavior. Please merge these definitions into a single entry that includes the necessary features.For example, you might update the earlier definition (line 34) and remove the duplicated entry at lines 45–48 as follows:
- tenderdash-proto = { git = "https://github.com/dashpay/rs-tenderdash-abci", version = "1.3.0", tag = "v1.3.0+1.3.0", default-features = false } + tenderdash-proto = { git = "https://github.com/dashpay/rs-tenderdash-abci", version = "1.3.0", tag = "v1.3.0+1.3.0", default-features = false, features = ["grpc", "serde"] }This change ensures a single, consistent configuration for the dependency and avoids potential future conflicts.
Action Required: Merge Duplicate
tenderdash-protoEntries in Cargo.toml
- The file
packages/dapi-grpc/Cargo.tomlcontains two definitions fortenderdash-proto(one starting at line 34 and another at lines 45–48).- TOML does not allow duplicate keys within the same table, which can lead to unpredictable behavior.
- To resolve this, merge the definitions into a single entry that includes the necessary
features(i.e.,"grpc"and"serde").For example, update:
- tenderdash-proto = { git = "https://github.com/dashpay/rs-tenderdash-abci", version = "1.3.0", tag = "v1.3.0+1.3.0", default-features = false } + tenderdash-proto = { git = "https://github.com/dashpay/rs-tenderdash-abci", version = "1.3.0", tag = "v1.3.0+1.3.0", default-features = false, features = ["grpc", "serde"] }This change ensures a single, consistent configuration for the dependency and avoids potential future conflicts.
🏁 Script executed:
#!/bin/bash # Search for all occurrences of "tenderdash-proto" in the Cargo.toml file rg --context 2 'tenderdash-proto' packages/dapi-grpc/Cargo.tomlLength of output: 1113
Merge Duplicate
tenderdash-protoDependency Definition in Cargo.tomlThe shell script output confirms that there are two definitions for
tenderdash-protoin the[dependencies]section. TOML does not support duplicate keys, which can lead to unexpected behavior. To resolve this, please merge the duplicate entries into a single definition that includes the necessary features.For example, update the earlier definition as follows:
- tenderdash-proto = { git = "https://github.com/dashpay/rs-tenderdash-abci", version = "1.3.0", tag = "v1.3.0+1.3.0", default-features = false } + tenderdash-proto = { git = "https://github.com/dashpay/rs-tenderdash-abci", version = "1.3.0", tag = "v1.3.0+1.3.0", default-features = false, features = ["grpc", "serde"] }This change ensures a single, consistent configuration for the dependency and avoids any potential future conflicts.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs (4)
99-100: Address the TODO for refetch and reject senders.
Refetching chunks or rejecting senders may be necessary for partial failures or malicious peers. Completing this logic will ensure robust snapshot handling.Do you want help drafting the logic for refetching chunks or rejecting senders?
158-274: Consider version alignment.
The calls toPlatformVersion::latest()might cause unintended behavior if the platform version changes during the synchronization phase. Storing and reusing a “negotiated” platform version for the entire sync process can eliminate potential mismatches.
276-312: Future-proof masternode type handling.
Currently, onlyMasternodeType::Evois recognized as HPMNs. If more masternode types become relevant later, consider a more flexible approach (e.g., a match statement) that will scale with additional types.
366-443: Streamline fall-through in sorting logic.
When sorting validator sets by core block height and then by hash, double-check that re-comparing the block height in thethen_withclause (lines 435-436) is needed—it might be redundant.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (3)
packages/dapi-grpc/Cargo.toml(1 hunks)packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs(1 hunks)packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/v0/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/rs-drive/src/drive/platform_state/fetch_last_block_info_bytes/v0/mod.rs
- packages/dapi-grpc/Cargo.toml
⏰ Context from checks skipped due to timeout of 90000ms (19)
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (wasm-dpp) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp) / Formatting
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (json-schema-compatibility-validator) / Linting
- GitHub Check: Rust packages (json-schema-compatibility-validator) / Tests
- GitHub Check: Rust packages (json-schema-compatibility-validator) / Unused dependencies
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Rust packages (dash-sdk) / Linting
- GitHub Check: Rust packages (dapi-grpc) / Linting
- GitHub Check: Rust packages (dapi-grpc) / Tests
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (4)
packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs (4)
1-37: No issues found in imports.
The import statements appear consistent and necessary for the file’s functionality.
50-60: Solid concurrency handling with RwLock.
Acquiring the write lock on the session here prevents data races and ensures safe, sequential updates to the state sync session.
104-156: Clean completion and verification flow.
Upon detecting state sync is done, you consume the session, commit it, and verify the updated database. This well-structured block ensures that incomplete or corrupted state does not progress.
314-364: Validate quorum set size growth.
This code only extendscurrent_quorums_mut()without accommodating removal of outdated/unused quorums. Verify that unrestricted growth incurrent_quorumsover time is intended or necessary.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs (4)
50-56: Ensure robust lock error handling when the RwLock is poisoned.
While you are correctly returning an error if the lock is poisoned, consider adding context logs or metrics to aid debugging if lock poisoning becomes frequent.
96-101: Clarify the usage ofrefetch_chunksandreject_senders.
Currently, these vectors are always empty. If you plan to implement chunk refetch or sender rejection based on failed validation, add handling logic or remove the TODO comments to avoid confusion.
276-312: Unit test coverage for masternode list rebuilding is advisable.
This code builds and extends masternode lists but relies heavily oncore_rpccalls. Consider adding mock-based unit tests confirming that onlyEvonodes are added to the HPMN list, for instance, to reduce future regression.Would you like me to suggest a sample test that uses a mock Core RPC client to validate
build_masternode_lists?
426-439: Double-check reversed order in validator set sorting.
You appear to sort by descendingcore_heightfirst (quorum_b.core_height()vs.quorum_a.core_height()) which results in the largest height first. If your code or your system logic expects ascending block height order, ensure that the order is correct.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (17)
- GitHub Check: Rust packages (wasm-dpp) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Detect immutable structure changes
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Rust packages (dash-sdk) / Unused dependencies
- GitHub Check: Rust packages (dash-sdk) / Linting
- GitHub Check: Rust packages (rs-dapi-client) / Tests
- GitHub Check: Rust packages (rs-dapi-client) / Linting
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (4)
packages/rs-drive-abci/src/abci/handler/apply_snapshot_chunk.rs (4)
125-145: Validateincorrect_hasheshandling and enforce final platform consistency checks.
It’s good to detect incorrect Grovedb hashes, but this block might benefit from an explicit verification path or logging that details which hashes are out of sync. This could significantly reduce the effort needed to troubleshoot if data corruption occurs.
187-203: Confirm if zeroed fields in the block info are acceptable.
All of these block fields (quorum_hash,block_id_hash,proposer_pro_tx_hash,signature,round) default to zero arrays. If this is intentional for newly created sync states, consider adding a comment or referencing the reason. If it’s unintentional, ensure these fields are correctly populated.
190-197: Good handling ofapp_hashconversion without panicking.
By using manual error handling and returning anAbciError, you address the previous feedback about avoiding.unwrap(). This approach improves robustness against unexpected hash lengths.
400-409: Check stable sorting requirements for quorums.
When you sort byheightand then byhash, confirm that the sort is stable if that’s required for determining a deterministic ordering. Some Rust sorting algorithms are stable, but verifying it is crucial for consensus-critical data.
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
New Features
Dependency Updates
Refactor & Improvements