feat(platform): optional token costs for document actions #2498
Conversation
WalkthroughThis pull request introduces extensive enhancements and refactoring across data contract and drive modules. It adds new token configuration fields, extends document type accessors with version 1 methods, and consolidates methods into basic traits. Numerous deprecated v0 modules have been removed and replaced with structured, versioned implementations. Additionally, token cost functionality has been integrated into document transition operations with support for token burns, and several tests and contract version constants have been updated to reflect these changes. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant DocumentType
participant TransitionProcessor
participant DriveOperations
participant TokenModule
Client->>DocumentType: Request document creation
DocumentType-->>TransitionProcessor: Validate document details
TransitionProcessor->>TokenModule: Check for token cost
alt Token cost exists
TokenModule-->>TransitionProcessor: Return token burn operation
else No token cost
TokenModule-->>TransitionProcessor: Return no token operation
end
TransitionProcessor->>DriveOperations: Build batch operations
DriveOperations-->>Client: Document Create Transition processed
Suggested reviewers
Poem
Tip ⚡🧪 Multi-step agentic review comment chat (experimental)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (30)
packages/rs-drive/src/drive/document/paths.rs (1)
4-4: Remove unused import.The static analysis tool indicates that
DocumentTypeBasicMethodsis not referenced in this file. To keep the codebase clean and avoid confusion, consider removing this import if it is truly unnecessary.- use dpp::data_contract::document_type::methods::DocumentTypeBasicMethods;🧰 Tools
🪛 GitHub Check: Rust packages (dash-sdk) / Linting
[warning] 4-4:
warning: unused import:dpp::data_contract::document_type::methods::DocumentTypeBasicMethods
--> packages/rs-drive/src/drive/document/paths.rs:4:5
|
4 | use dpp::data_contract::document_type::methods::DocumentTypeBasicMethods;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^packages/rs-dpp/src/document/extended_document/v0/mod.rs (1)
35-35: Verify usage of newly introduced import.
DocumentTypeBasicMethodsdoes not appear to be invoked in this file. If this import is unneeded, removing it can reduce clutter. Otherwise, please ensure references to its methods are properly integrated.- use crate::data_contract::document_type::methods::DocumentTypeBasicMethods;packages/rs-drive/src/drive/contract/update/update_contract/v0/mod.rs (1)
16-16: Consider removing the unused import.Similar to other files, no direct usage of
DocumentTypeBasicMethodsappears in this file. Unless new references to its methods will be added, removing this import can prevent confusion and lint warnings.- use dpp::data_contract::document_type::methods::DocumentTypeBasicMethods;packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/mod.rs (2)
1-14: Add inline documentation for crucial data structures.Since this is a new module with potentially central functionality, consider adding Rust doc comments (
/// ...) for the module itself, as well as for each import representing standalone functionality. This helps future contributors quickly understand intent and usage.
15-26: Provide trait-level documentation.Declare
///doc comments on theDocumentBaseTransitionActionValidationtrait to outline its core responsibilities (e.g., “Validates document base transition actions against platform state”). This fosters clarity for implementers and maintainers.packages/rs-drive/src/state_transition_action/batch/batched_transition/token_transition/token_claim_transition_action/v0/transformer.rs (1)
248-260: Removed unnecessary mutabilityGood cleanup - the variable
distributions_in_past_for_owneris now properly declared as immutable since it's not modified after initialization. This follows the Rust best practice of minimizing mutability when possible.packages/rs-dpp/src/data_contract/document_type/accessors/v0/mod.rs (1)
88-90: Encourage adding documentation or usage example.The new setter
set_data_contract_idis straightforward, but consider adding a minor code example or doc comment explaining when and why to update the data contract ID at runtime. This helps future contributors understand its purpose.packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs (2)
19-56: Centralize matching logic for getters.Delegating getters to the
V0variant is straightforward. As new versions arrive, ensure you do not replicate logic unnecessarily. A small note: consider whether you want a unified fallback or if explicit matches for each version remain best.
58-112: Streamline setter patterns.These setters mirror the getters, which is excellent for maintainability. Keep an eye out for potential ways to reduce boilerplate if more cost fields are added. For instance, delegating logic through a single helper could reduce repetitive match statements in future expansions.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (1)
2364-2389: Well-implemented token contract creation utilityThis function provides a clean way to create a card game token contract with in-game currency for testing purposes. It properly handles initialization of the contract, sets appropriate timestamps, and calculates token IDs.
Consider adding documentation comments that explain the purpose of this function and the relationship between the two token IDs it returns. This would make it clearer for other developers what each token represents in the card game context.
+ /// Creates a card game token contract with the specified identity as owner. + /// Returns the contract and two token IDs: + /// - The first token ID represents the primary in-game currency + /// - The second token ID represents the secondary token type in the game pub(in crate::execution) fn create_card_game_token_contract_with_owner_identity( platform: &mut TempPlatform<MockCoreRPCLike>, identity_id: Identifier, platform_version: &PlatformVersion, ) -> (DataContract, Identifier, Identifier) {packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/nft.rs (1)
2802-3143: Consider extracting repeated logic into smaller helpers.This new test function comprehensively covers the scenario of setting the document price and purchasing it with token costs, verifying ownership and token balances. The flow is correct, and the assertions appear consistent. However, the test is relatively large and includes similar code segments (e.g., steps to apply transitions or check balances) that appear in other NFT-related tests. To improve maintainability, consider extracting repeated logic (such as asset/transitions setup, repeated balance checks, etc.) into reusable helper functions or fixtures.
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (1)
60-595: The function is comprehensive but might be refactored for clarity.The
try_from_schemamethod thoroughly handles:
- Base schema enrichment
- Optional field defaults and fallbacks
- Validation checks for document structure, indices, and property constraints
- Token cost extraction
Because it manages numerous parameters (configuration, validation features, schema expansions, and indexing logic), the body is quite extensive. For long-term maintainability, consider refactoring it into smaller helper methods or modules (e.g., one for index initialization, another for property extraction). This approach can maintain clarity, keep the logic modular, and reduce the chance of introducing subtle bugs in the future.
packages/rs-dpp/src/data_contract/document_type/v1/random_document_type.rs (1)
10-23: Function logic appears correct.This helper wraps
DocumentTypeV0::random_document_typeand casts the result toDocumentTypeV1, ensuring backward compatibility. Consider adding specific unit tests forrandom_document_typeto confirm correct usage in v1 context.packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs (2)
35-37: Address the static analysis warning on unused imports.Static analysis flags these constants as unused under certain build configurations. Wrap them in
#[cfg(feature = "validation")]if they are meant for validation-only usage, to avoid confusion.#[cfg(feature = "validation")] use crate::data_contract::document_type::class_methods::try_from_schema::{ - MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH, MAX_INDEXED_STRING_PROPERTY_LENGTH, - NOT_ALLOWED_SYSTEM_PROPERTIES, SYSTEM_PROPERTIES, + MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH, + MAX_INDEXED_STRING_PROPERTY_LENGTH, + NOT_ALLOWED_SYSTEM_PROPERTIES, + SYSTEM_PROPERTIES, };🧰 Tools
🪛 GitHub Check: Rust packages (dash-sdk) / Linting
[warning] 36-36:
warning: unused imports:MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH,MAX_INDEXED_STRING_PROPERTY_LENGTH,NOT_ALLOWED_SYSTEM_PROPERTIES, andSYSTEM_PROPERTIES
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs:36:5
|
36 | MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH, MAX_INDEXED_STRING_PROPERTY_LENGTH,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
37 | NOT_ALLOWED_SYSTEM_PROPERTIES, SYSTEM_PROPERTIES,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
60-60: Consider splitting this large function.
try_from_schemais carrying multiple responsibilities (property extraction, schema validation, index checks, etc.). Refactoring into smaller helper methods would improve maintainability.packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (1)
4-47: Consider consolidating into a single operation-based method.
All these getters share similar logic. If future maintenance introduces additional cost variants, having one method that takes an enum or specific operation type might improve scalability and reduce code duplication.packages/rs-drive/src/drive/tokens/system/remove_from_token_total_supply/v0/mod.rs (1)
102-109: Encapsulate the direct query type logic in a helper function.
This logic neatly chooses betweenStatefulDirectQueryandStatelessDirectQuery, but it's duplicated in other parts of the codebase for token operations (e.g., “add_to_token_total_supply”). Refactoring it into a helper method would enhance maintainability and consistency.packages/rs-dpp/src/data_contract/document_type/methods/mod.rs (1)
269-274: Consider refining the method name for clarity.
prefunded_voting_balance_for_documentmight be clearer asminimum_prefunded_voting_balance_for_document. This conveys that the returned balance is a minimal requirement rather than a final or arbitrary balance.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_delete_transition_action/state_v0/mod.rs (1)
40-55: Early return on failed state validation
The call toself.base().validate_state(...)with a timely exit on invalid results is a clean way to prevent unnecessary processing. Consider logging or tracing errors to help diagnose validation failures at runtime.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_update_price_transition_action/state_v0/mod.rs (1)
32-33: Meaningful parameter usage
Previously unused_block_infoand_execution_contextare now used, removing the underscore prefix would improve clarity since they’re genuinely in use.packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/mod.rs (2)
18-19: New v1 module
Defining a dedicatedv1module helps cleanly segregate newer schema logic. Ensure full coverage with unit and integration tests to validate all versioned code paths.
159-264:insert_values_nestedmethod scope
This method parallelsinsert_valuesbut adds an even deeper nesting layer. Consider consolidating shared functionality or employing a recursive helper to reduce code duplication. Monitor performance for large or deeply nested schemas.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/state_v0/mod.rs (1)
15-26: Encapsulate version-based logic in separate modulesThe new trait specifically references "v0" in its name. If you plan to have future versions, consider placing all version-specific logic under versioned modules to maintain clarity. The name is consistent with the existing pattern, but ensure you also have a clear path for future expansions (e.g.,
validate_state_v1) if the logic changes substantially.packages/rs-drive-abci/tests/supporting_files/contract/crypto-card-game/crypto-card-game-in-game-currency.json (1)
2-2: Document immutability replaced withdocumentsMutable: trueand new tokenCost fieldsChanging
documentsMutabletotruepotentially affects the game logic, allowing modifications after creation. Make sure the contract logic or transitions handle this new mutability properly.
Additionally, the newly introducedtokenCostobject clearly outlines cost structures for create, delete, replace, transfer, update_price, and purchase actions, which is beneficial for clarity.Consider adding a short comment or a higher-level note in the JSON to document the rationale for each token cost, especially if these values correlate to in-game economy or design decisions.
Also applies to: 9-9, 13-20
packages/rs-dpp/src/data_contract/document_type/mod.rs (3)
17-23: New modules for token costs and version handlingThe addition of
mod token_costsandpub mod v1indicates a growing modular structure for versioned documents and their token cost logic. Ensure that any helper functions or utilities related to these modules remain consistent and are reusable across different versions, preventing code duplication.
24-39: Consistent naming for trait referencesReferring to
DocumentTypeBasicMethodsandDocumentTypeV0Methodsside by side might cause confusion for future expansions. Consider establishing a naming convention or domain-based grouping for these trait references, so the differences between “basic” and “versioned” methods remain clear.
79-95: Extend documentation for newV1variantsIntroducing a
V1variant inDocumentTypeRef,DocumentTypeMutRef, andDocumentTypeis a key expansion. We recommend adding documentation clarifying howV0andV1differ in practice or linking to relevant docs explaining version migrations.packages/rs-dpp/src/data_contract/document_type/methods/versioned_methods.rs (2)
30-193: Comprehensive document creation method.
create_document_from_data_v0handles ID generation, timestamps, block heights, and revision logic thoroughly. The repeated checks for required fields are correct but somewhat lengthy. Consider extracting the timestamp/block-height logic into a helper to reduce complexity.
195-343: Parallel method for creation with prevalidated properties.
create_document_with_prevalidated_properties_v0mirrors the previous logic, ensuring consistent handling of timestamps and heights. The duplication is understandable but could benefit from shared utilities if future expansions arise.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/transformer.rs (1)
19-20: Pass function parameter as struct for extensibility.
You might consider wrappingget_data_contractandget_token_costclosures in a small helper struct if these parameters keep growing. This can improve readability by clarifying the intent and grouping related arguments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (107)
packages/rs-dpp/src/data_contract/associated_token/token_configuration/v0/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs(3 hunks)packages/rs-dpp/src/data_contract/document_type/accessors/v0/mod.rs(2 hunks)packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/mod.rs(3 hunks)packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs(11 hunks)packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/methods/contested_vote_poll_for_document/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/contested_vote_poll_for_document/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/create_document_from_data/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/create_document_from_data/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/create_document_with_prevalidated_properties/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/create_document_with_prevalidated_properties/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/deserialize_value_for_key/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/deserialize_value_for_key/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/estimated_size/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/estimated_size/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/index_for_types/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/index_for_types/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/max_size/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/max_size/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/mod.rs(5 hunks)packages/rs-dpp/src/data_contract/document_type/methods/prefunded_voting_balances_for_document/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/prefunded_voting_balances_for_document/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/serialize_value_for_key/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/serialize_value_for_key/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/methods/versioned_methods.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/mod.rs(4 hunks)packages/rs-dpp/src/data_contract/document_type/random_document.rs(9 hunks)packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/token_costs/v0/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/v0/accessors.rs(3 hunks)packages/rs-dpp/src/data_contract/document_type/v0/mod.rs(2 hunks)packages/rs-dpp/src/data_contract/document_type/v0/random_document.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/v1/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/document_type/v1/random_document_type.rs(1 hunks)packages/rs-dpp/src/data_contract/methods/validate_document/v0/mod.rs(2 hunks)packages/rs-dpp/src/data_contract/methods/validate_update/v0/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/v0/accessors/mod.rs(2 hunks)packages/rs-dpp/src/data_contract/v1/accessors/mod.rs(2 hunks)packages/rs-dpp/src/document/extended_document/v0/mod.rs(1 hunks)packages/rs-dpp/src/document/v0/serialize.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/mod.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/mod.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs(3 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/state_v0/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_create_transition_action/state_v1/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_delete_transition_action/state_v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_purchase_transition_action/state_v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_replace_transition_action/state_v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_transfer_transition_action/state_v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_update_price_transition_action/state_v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/withdrawals/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs(5 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/deletion.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/nft.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/replacement.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/transfer.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/mod.rs(0 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs(2 hunks)packages/rs-drive-abci/src/query/document_query/v0/mod.rs(0 hunks)packages/rs-drive-abci/tests/supporting_files/contract/basic-token-with-document/basic-token-with-document.json(1 hunks)packages/rs-drive-abci/tests/supporting_files/contract/crypto-card-game/crypto-card-game-in-game-currency.json(2 hunks)packages/rs-drive/src/drive/contract/insert/insert_contract/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/contract/update/update_contract/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/document/insert/add_document_to_primary_storage/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/document/insert/add_reference_for_index_level_for_contract_operations/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/document/insert_contested/add_contested_document_to_primary_storage/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/document/insert_contested/add_contested_reference_and_vote_subtree_to_document_operations/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/document/paths.rs(1 hunks)packages/rs-drive/src/drive/document/update/internal/update_document_for_contract_operations/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/distribution/add_pre_programmed_distribution/v0/mod.rs(0 hunks)packages/rs-drive/src/drive/tokens/distribution/mark_perpetual_release_as_distributed/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/distribution/mark_pre_programmed_release_as_distributed/v0/mod.rs(0 hunks)packages/rs-drive/src/drive/tokens/estimated_costs/for_token_perpetual_distribution/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/estimated_costs/for_token_total_supply/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/system/add_to_token_total_supply/mod.rs(2 hunks)packages/rs-drive/src/drive/tokens/system/add_to_token_total_supply/v0/mod.rs(2 hunks)packages/rs-drive/src/drive/tokens/system/remove_from_token_total_supply/v0/mod.rs(2 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_create_transition.rs(4 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_delete_transition.rs(3 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_purchase_transition.rs(5 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_replace_transition.rs(5 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_transfer_transition.rs(5 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_update_price_transition.rs(4 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/mod.rs(2 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/transformer.rs(3 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs(3 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/transformer.rs(2 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/mod.rs(1 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs(3 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/v0/transformer.rs(3 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_purchase_transition_action/v0/transformer.rs(2 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/v0/transformer.rs(2 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_transfer_transition_action/v0/transformer.rs(2 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_update_price_transition_action/v0/transformer.rs(2 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/token_transition/token_claim_transition_action/v0/transformer.rs(1 hunks)packages/rs-drive/src/util/batch/drive_op_batch/token.rs(0 hunks)packages/rs-drive/src/util/object_size_info/document_info.rs(1 hunks)packages/rs-drive/src/util/operations/apply_batch_low_level_drive_operations/v0/mod.rs(1 hunks)packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/v2.rs(1 hunks)
⛔ Files not processed due to max files limit (7)
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_validation_versions/mod.rs
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_validation_versions/v1.rs
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_validation_versions/v2.rs
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_validation_versions/v3.rs
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_validation_versions/v4.rs
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_validation_versions/v5.rs
- packages/rs-sdk/src/platform/transition/update_price_of_document.rs
💤 Files with no reviewable changes (24)
- packages/rs-dpp/src/data_contract/document_type/methods/estimated_size/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/create_document_from_data/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/prefunded_voting_balances_for_document/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/create_document_with_prevalidated_properties/mod.rs
- packages/rs-drive/src/util/batch/drive_op_batch/token.rs
- packages/rs-drive-abci/src/query/document_query/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/deserialize_value_for_key/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/index_for_types/mod.rs
- packages/rs-drive/src/drive/tokens/distribution/add_pre_programmed_distribution/v0/mod.rs
- packages/rs-drive/src/drive/tokens/distribution/mark_pre_programmed_release_as_distributed/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/max_size/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/serialize_value_for_key/mod.rs
- packages/rs-dpp/src/data_contract/document_type/v0/random_document.rs
- packages/rs-dpp/src/data_contract/document_type/methods/prefunded_voting_balances_for_document/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/contested_vote_poll_for_document/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/index_for_types/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/create_document_from_data/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/max_size/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/deserialize_value_for_key/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/serialize_value_for_key/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/estimated_size/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/create_document_with_prevalidated_properties/v0/mod.rs
- packages/rs-dpp/src/data_contract/document_type/methods/contested_vote_poll_for_document/mod.rs
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/mod.rs
🧰 Additional context used
🪛 GitHub Check: Rust packages (dash-sdk) / Linting
packages/rs-drive/src/drive/document/paths.rs
[warning] 4-4:
warning: unused import: dpp::data_contract::document_type::methods::DocumentTypeBasicMethods
--> packages/rs-drive/src/drive/document/paths.rs:4:5
|
4 | use dpp::data_contract::document_type::methods::DocumentTypeBasicMethods;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs
[warning] 36-36:
warning: unused imports: MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH, MAX_INDEXED_STRING_PROPERTY_LENGTH, NOT_ALLOWED_SYSTEM_PROPERTIES, and SYSTEM_PROPERTIES
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:36:42
|
36 | insert_values, insert_values_nested, MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
37 | MAX_INDEXED_STRING_PROPERTY_LENGTH, NOT_ALLOWED_SYSTEM_PROPERTIES, SYSTEM_PROPERTIES,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
[warning] 11-11:
warning: unused import: DocumentPropertyType
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:11:71
|
11 | use crate::data_contract::document_type::property::{DocumentProperty, DocumentPropertyType};
| ^^^^^^^^^^^^^^^^^^^^
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs
[warning] 36-36:
warning: unused imports: MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH, MAX_INDEXED_STRING_PROPERTY_LENGTH, NOT_ALLOWED_SYSTEM_PROPERTIES, and SYSTEM_PROPERTIES
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs:36:5
|
36 | MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH, MAX_INDEXED_STRING_PROPERTY_LENGTH,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
37 | NOT_ALLOWED_SYSTEM_PROPERTIES, SYSTEM_PROPERTIES,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
⏰ Context from checks skipped due to timeout of 90000ms (20)
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (drive-abci) / Detect immutable structure changes
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Formatting
- GitHub Check: Rust packages (wasm-dpp) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (drive) / Unused dependencies
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Unused dependencies
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Tests
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (169)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/mod.rs (1)
28-63: Versioned method dispatch looks correct.The version-based dispatch into
validate_state_v0is well-structured and aligns with the codebase’s typical approach to multi-version support. However, ensure that other versions (1, 2, etc.) are handled as this feature matures.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/mod.rs (1)
1-1: Well-structured module addition for token handlingThe addition of the
document_base_transaction_actionmodule establishes the foundation for token requirement validation across document actions, which aligns with the PR objective of requiring tokens for document actions.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/mod.rs (1)
5-6: Appropriate import for token distribution functionalityThe addition of the
TokenDistributionTypeimport supports the token requirement functionality being added across document operations, particularly for token claim transitions as seen in the implementation at lines 929-978.packages/rs-dpp/src/data_contract/associated_token/token_configuration/v0/mod.rs (1)
26-27: Added base_supply field with default value handlingThe
#[serde(default)]attribute ensures backward compatibility by providing a default value during deserialization when the field is not present in existing data. This is appropriate for introducing a new required field without breaking existing contracts.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/mod.rs (1)
9-10: Import added for token contract testingThe import of
create_card_game_token_contract_with_owner_identityfunction will enable testing of the token requirements for document actions, which is consistent with the PR's objective.packages/rs-drive/src/drive/contract/insert/insert_contract/v0/mod.rs (1)
15-15: Good refactoring to use more generic traitChanging from
DocumentTypeV0MethodstoDocumentTypeBasicMethodsaligns with the PR's goal of generalizing document operations and preparing for token requirements. This refactoring to use more generic traits improves maintainability by reducing version-specific code.packages/rs-drive/src/util/object_size_info/document_info.rs (1)
13-13: Good refactoring to use more generic traitChanging from
DocumentTypeV0MethodstoDocumentTypeBasicMethodsis consistent with the overall refactoring being done across the codebase. This approach reduces version-specific code and improves maintainability.packages/rs-dpp/src/data_contract/v1/accessors/mod.rs (1)
12-14: Clean refactoring of document type handling.The code now uses the
DocumentTypeV0Setterstrait directly instead of likely handling document type variants through pattern matching. This is a cleaner approach that improves maintainability and makes future extensions easier.Also applies to: 118-118
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_total_supply/v0/mod.rs (1)
95-95: Appropriate optimization for token supply tracking.Changing from
TreeType::NormalTreetoTreeType::BigSumTreefor the total tokens root supply path is a good optimization. This will improve the efficiency of managing token totals, which is crucial for the new token requirement feature.packages/rs-drive/src/drive/tokens/distribution/mark_perpetual_release_as_distributed/v0/mod.rs (1)
1-1: Clean removal of unused imports.The import has been simplified to only include what's actually used in this module. This is good housekeeping that improves code readability.
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/mod.rs (1)
5-5: Successfully implemented token cost support for document actions.This change adds the necessary functionality to access token costs associated with document transitions. The new
token_cost()method returns both the token identifier and amount as an option, which is exactly what's needed to implement the token requirement feature described in the PR objectives.Also applies to: 80-84
packages/rs-drive/src/drive/document/insert_contested/add_contested_reference_and_vote_subtree_to_document_operations/v0/mod.rs (1)
17-17:❓ Verification inconclusive
Import refactored from specific to more generic trait.
The import change from
DocumentTypeV0MethodstoDocumentTypeBasicMethodsaligns with the PR's effort to consolidate document type methods across the codebase. This promotes better maintainability by using a more consistent and version-agnostic approach.However, I don't see this trait explicitly used in this file. If it's not required, consider removing it.
🏁 Script executed:
#!/bin/bash # Check if DocumentTypeBasicMethods is actually used in this file grep -r "DocumentTypeBasicMethods" packages/rs-drive/src/drive/document/insert_contested/add_contested_reference_and_vote_subtree_to_document_operations/v0/mod.rsLength of output: 236
Verify the necessity of the DocumentTypeBasicMethods import
The refactor to use the generic trait is in line with the overall PR goals. However, our automated check indicates that the only occurrence of
DocumentTypeBasicMethodsin this file is the import itself—there’s no explicit usage visible. Please verify if this import is needed to bring extension methods into the scope implicitly (e.g., via method calls on document objects) or if it’s truly redundant. If it turns out to be unnecessary, consider removing it to keep the code clean.packages/rs-dpp/src/data_contract/v0/accessors/mod.rs (2)
9-11: Import for document type accessors added.The added imports for
DocumentTypeV0GettersandDocumentTypeV0Settersenable the use of these traits in this module, which supports the implementation changes below.
109-109: Improved implementation using setter traits.The implementation of
set_idhas been simplified by directly using theset_data_contract_idmethod from the importedDocumentTypeV0Setterstrait instead of a match statement. This makes the code more maintainable and resilient to future document type structure changes.- .for_each(|(_, document_type)| match document_type { - DocumentType::V0(document_type) => { - document_type.data_contract_id = id; - } - }) + .for_each(|(_, document_type)| document_type.set_data_contract_id(id))packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/mod.rs (1)
13-13: Import refactored from specific to more generic trait.Similar to the previous file, this change from
DocumentTypeV0MethodstoDocumentTypeBasicMethodscontributes to the broader refactoring effort that consolidates document type methods across the codebase. This promotes consistency and eases future maintenance.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/withdrawals/v0/mod.rs (2)
171-171: Added token_cost field to support new token functionality.The
token_costfield has been added to theDocumentBaseTransitionActionV0struct creation with a default value ofNone. This aligns with the PR's objective to implement token requirements for document actions.
314-314: Added token_cost field for consistency in test cases.Similar to the previous instance, the
token_costfield has been added here to maintain consistent structure in the test cases. Setting it toNoneis appropriate for these tests since they're not directly testing token functionality.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/v0/transformer.rs (2)
5-5: Added token cost capability for document replacement.The new import of
DocumentTypeV1Gettersenables access to document replacement token cost functionality.
37-37:✅ Verification successful
Integrated token cost retrieval for document replacement operations.
The added closure retrieves document replacement token costs during transition processing, implementing the token requirement for document replacement actions.
🏁 Script executed:
#!/bin/bash # Check where this token cost retrieval is being used in the codebase rg -A 3 "document_replacement_token_cost" --type rustLength of output: 8694
Integrated document replacement token cost retrieval is correctly implemented.
The closure in
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/v0/transformer.rsaccurately callsdocument_replacement_token_cost(), aligning with similar usage across the codebase (as seen in thers-dppmodules). No removed or replaced code is missing, and the integrated token cost retrieval meets the design requirements.packages/rs-drive/src/drive/document/insert/add_reference_for_index_level_for_contract_operations/v0/mod.rs (1)
18-18: Updated import to use consolidated document type methods.The import change from
DocumentTypeV0MethodstoDocumentTypeBasicMethodsindicates a refactoring toward version-agnostic document handling, improving code maintainability and reducing duplication across document type versions.packages/rs-drive/src/drive/tokens/estimated_costs/for_token_perpetual_distribution/v0/mod.rs (3)
2-4: Optimized imports for token distribution paths.Streamlined the imports to include only the necessary token distribution path functions.
6-6: Simplified type constant imports.Optimized to include only the necessary type constants used in the file.
8-9: Refined GroveDB estimation imports.Removed unused imports and retained only the necessary estimation-related components.
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_transfer_transition_action/v0/transformer.rs (2)
6-6: Added token cost capability for document transfer.The new import of
DocumentTypeV1Gettersenables access to document transfer token cost functionality.
30-30:✅ Verification successful
Integrated token cost retrieval for document transfer operations.
The added closure retrieves document transfer token costs during transition processing, implementing the token requirement for document transfer actions.
🏁 Script executed:
#!/bin/bash # Check where this token cost retrieval is being used in the codebase rg -A 3 "document_transfer_token_cost" --type rustLength of output: 8625
Token Cost Retrieval Integration Confirmed
The closure now correctly retrieves the document transfer token cost using
|document_type| document_type.document_transfer_token_cost(),which is consistently in use across the codebase. No removal or additional changes are required.
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_update_price_transition_action/v0/transformer.rs (2)
6-6: Added import for retrieving token costs from document typesThe import of
DocumentTypeV1Gettersenables access to token cost information from V1 document types, supporting the implementation of token requirements for document actions mentioned in the PR.
26-26: Token cost retrieval implemented for document update price transitionsThe added closure retrieves the token cost specifically for document update price transitions, aligning with the PR objective to require tokens for document actions.
packages/rs-dpp/src/document/v0/serialize.rs (1)
18-18: Refactored to use more generic DocumentTypeBasicMethods traitThe change from
DocumentTypeV0MethodstoDocumentTypeBasicMethodssuggests a strategic shift toward a more reusable, version-agnostic approach for document serialization. This change improves code maintainability while supporting the token functionality additions across the codebase.packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/v2.rs (1)
30-30: Updated to use document type V1 for schema conversionThe version change from 0 to 1 for
try_from_schemaupdates the platform to use V1 document types, which include token cost functionality. This is a critical change that enables token requirements for document actions as specified in the PR.packages/rs-drive/src/drive/document/insert_contested/add_contested_document_to_primary_storage/v0/mod.rs (1)
29-29: Added DocumentTypeBasicMethods to importsImporting both
DocumentTypeBasicMethodsandDocumentTypeV0Methodsenhances flexibility by allowing the code to use common methods from the basic trait while maintaining access to version-specific functionality. This change supports the broader refactoring toward cleaner version handling.packages/rs-drive/src/drive/document/update/internal/update_document_for_contract_operations/v0/mod.rs (1)
32-32: Migration to DocumentTypeBasicMethodsThis change reflects a shift from version-specific methods to more generalized, shared traits. The
DocumentTypeBasicMethodstrait likely consolidates common functionality that was previously duplicated across different document type versions.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_purchase_transition_action/v0/transformer.rs (2)
6-6: Import for token cost functionalityAdding the
DocumentTypeV1Gettersimport enables access to token-related getter methods for document types, specifically from the V1 API.
27-27: Added token cost retrieval for document purchasesThis change implements token cost functionality for document purchases by passing a closure that retrieves the document purchase token cost from the document type. This aligns with the PR objective of requiring tokens for document actions.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/mod.rs (1)
23-23: Migration to more generalized document type methodsSimilar to other files in this PR, this change shifts from version-specific methods to a more generalized approach with
DocumentTypeBasicMethods. This promotes code reuse and simplifies maintenance across different document type versions.packages/rs-drive-abci/tests/supporting_files/contract/basic-token-with-document/basic-token-with-document.json (1)
1-157: Well-structured token integration for document operations.This new contract file implements token costs for document operations, which aligns with the PR objective of requiring tokens for document actions. The implementation includes:
- Token costs defined for create/replace/delete operations with different amounts
- Comprehensive document schema with proper constraints and validations
- Well-structured indices to support efficient queries
- Token definition with appropriate supply configuration
A few things to note:
- The document type is non-mutable and non-deletable (
documentsMutable: false,canBeDeleted: false), but token costs are still defined for replace and delete operations which won't be used- The transferable flag is set to 1, enabling document transfers
packages/rs-dpp/src/data_contract/document_type/v0/mod.rs (2)
9-14: Clean import organization with proper feature flagging.The import restructuring improves code organization by grouping related trait imports together and properly conditionally importing the validator only when the validation feature is enabled.
66-68: Good trait implementation that enhances code reusability.Adding
DocumentTypeBasicMethodsandDocumentTypeV0Methodstrait implementations forDocumentTypeV0improves code reusability and adheres to the DRY principle. This refactoring aligns with the modular approach seen in other parts of the codebase.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs (2)
30-32: Clean reorganization of token-related imports.The import statements have been rearranged to group related token transition types together, improving code readability.
48-49: Added support for token distribution types.Added the import for
TokenDistributionTypeunder the appropriate feature flag to support token claim distribution functionality, aligning with the PR objective of requiring tokens for document actions.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/mod.rs (3)
26-26: Added test helper for token management.Adding the
add_tokens_to_identityimport enables tests to set up token balances for identities, which is essential for testing the new token-required document actions.
29-35: Enhanced error handling support for token-related operations.Added imports for specific error types (
PaidConsensusError,StateError,ConsensusError) to properly handle and test error conditions that might occur when token operations fail, such as insufficient token balance.
36-36: Added support for V1 data contract getters.The
DataContractV1Gettersimport enables tests to work with V1 data contracts, which likely include the new token cost functionality for document operations.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs (3)
2-2: Good addition of DocumentTypeV1Getters importAdding the V1 getters import alongside V0 getters shows proper preparation for using the newer document type accessors while maintaining backward compatibility.
40-41: Token integration for document creation looks goodThis closure properly implements the token cost retrieval functionality for document creation transitions, which aligns with the PR's objective of requiring tokens for document actions.
137-138: Consistent token implementation across methodsGood consistency in implementing the same token cost retrieval mechanism in the borrowed document transition method, ensuring both entry points handle tokens properly.
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_create_transition.rs (4)
4-5: Good addition of TokenOperation importAdding TokenOperation to the import list is necessary for implementing token burns during document creation.
18-18: Proper import of TokenOperationTypeThe TokenOperationType import enables the use of specific token operations like TokenBurn.
49-50: Effective retrieval of token costGood implementation of retrieving the document creation token cost from the base action.
68-74: Well-implemented token burn operationThis conditional block properly handles token burning when a document creation token cost is specified. The implementation includes all necessary parameters: token_id, identity_balance_holder_id, and burn_amount.
packages/rs-dpp/src/data_contract/methods/validate_document/v0/mod.rs (2)
3-3: Simplified import statementGood simplification of the import statement to use the base DocumentType rather than a specific reference type.
49-49: Cleaner validator retrievalThis code simplification improves readability by directly accessing the JSON schema validator reference from the document type instead of pattern matching.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_create_transition_action/state_v1/mod.rs (2)
24-24: Good import of validation traitAdding the DocumentBaseTransitionActionValidation import supports the new validation step.
50-61: Proper validation flow with token checksThis addition properly implements base validation checks that likely include token requirements before proceeding with document-specific validations. The early return on validation failure is a good pattern to prevent unnecessary processing.
The "create" string parameter clearly identifies this as a document creation action for validation purposes.
packages/rs-drive/src/drive/document/insert/add_document_to_primary_storage/v0/mod.rs (1)
37-37: Added new import for DocumentTypeBasicMethods traitThe import statement now includes
DocumentTypeBasicMethodsalongside the existingDocumentTypeV0Methods. This seems to be part of a broader refactoring to consolidate common methods into basic traits that can be shared across versions.packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_transfer_transition.rs (4)
3-3: Added TokenOperation import for document transfer token burnsThe TokenOperation import has been added to support token burn operations for document transfers.
17-17: Added TokenOperationType importAdded import for TokenOperationType to define the specific token operation (burn).
38-38: Added document_transfer_token_cost retrievalNow retrieving the token cost associated with document transfer from the base action.
50-77: Modified operation building to include token burns when requiredThe code now:
- Initializes a mutable operations vector instead of directly returning
- Conditionally adds a TokenBurn operation when a token cost is specified
- Returns the updated operations vector
This change properly implements token burning for document transfers, aligning with the PR objective of requiring tokens for document actions.
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs (3)
4-4: Added TokenAmount importAdded import for TokenAmount to support token costs in document transitions.
24-25: Added token_cost field to DocumentBaseTransitionActionV0Added a new field to store the token cost (token ID and amount) associated with document transitions. The field is optional since not all transitions may require tokens.
53-54: Added token_cost accessor methodAdded a new accessor method to retrieve the token cost from the document base transition action.
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_update_price_transition.rs (4)
3-3: Added TokenOperation import for document price updatesAdded TokenOperation import to support token burn operations when updating document prices.
16-16: Added TokenOperationType importAdded import for TokenOperationType to define the specific token operation (burn).
37-37: Added document_update_price_token_cost retrievalNow retrieving the token cost associated with document price updates from the base action.
43-70: Modified operation building to include token burns when requiredThe code now:
- Initializes a mutable operations vector instead of directly returning
- Conditionally adds a TokenBurn operation when a token cost is specified
- Returns the updated operations vector
This change properly implements token burning for document price updates, aligning with the PR objective of requiring tokens for document actions.
packages/rs-dpp/src/data_contract/document_type/accessors/v0/mod.rs (2)
82-86: Ensure implementation consistency for json schema validator retrieval.The new API
json_schema_validator_refwill be hidden ifvalidationis disabled, which is fine. Just confirm that any calls to it are also wrapped with the appropriate feature checks or default to a no-op implementation in those configurations.
8-9:❓ Verification inconclusive
Validate the conditional compilation usage.
Using
#[cfg(feature = "validation")]is a clean way to optionally include logic. Ensure that downstream consumers compile with the right feature flag to use this validator. Otherwise, attempting to call the validation method without the feature might cause compilation issues.You can verify whether any parts of the codebase rely on this method without the "validation" feature by searching for direct calls:
🏁 Script executed:
#!/bin/bash # Searching for direct calls to `json_schema_validator_ref` outside `#[cfg(feature="validation")]` contexts ast-grep --pattern $'json_schema_validator_ref($_)'Length of output: 52
Action Required: Verify Conditional Compilation Context
The conditional compilation for importing
StatelessJsonSchemaLazyValidatorusing#[cfg(feature = "validation")]appears to be correctly implemented. However, our initial automated check for direct calls tojson_schema_validator_refdid not return any output. This absence of evidence might be due to limitations in the automated search, so it’s important to manually verify that no parts of the codebase rely on this validator when the "validation" feature is disabled.
- Confirm that no calls to
json_schema_validator_refexist outside of#[cfg(feature = "validation")]blocks.- Ensure that downstream consumers consistently compile with the correct feature flag to avoid potential compilation issues.
packages/rs-drive/src/drive/tokens/system/add_to_token_total_supply/mod.rs (1)
41-41: Maintain clarity with re-ordered arguments.Similarly, passing
block_infoafterapplycan be beneficial for readability (keeping booleans together). Just ensure that usage documentation or doc comments reflect the new parameter order to prevent confusion for other developers.packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs (3)
1-8: Introduce robust testing for token cost imports.These imports and module references are foundational for the new token cost logic. Ensure robust coverage tests exist for each scenario where
TokenAmount,TokenContractPosition, and theFromderivation might apply, especially if the enum expands.
9-11: Verify modular visibility.
pub(crate) mod accessors;limits its visibility to this crate. If the accessors are intended for broader usage, confirm thatpubis the correct visibility. Otherwise, no concerns here.
12-17: Confirm that future versions are planned.The new
TokenCostsenum introduces a versioned approach with a singleV0variant. This design is flexible for future expansions. Ensure that any necessary version checks or fallback logic are appropriately documented so future contributors know how to addV1or higher.packages/rs-dpp/src/data_contract/document_type/token_costs/v0/mod.rs (4)
1-6: Appropriate imports for token cost functionalityThe imports include necessary components for handling token costs, such as
TokenAmountfrom the balances module, and the accessor traits for getting and setting token costs.
7-27: Well-structured token costs model with clear documentationThe
TokenCostsV0struct provides a clean encapsulation of token costs for various document operations, with each field properly documented. The use ofOptiontypes appropriately handles cases where costs might not be set for certain operations.
29-54: Clean getter implementation with proper cloningThe implementation of the
TokenCostGettersV0trait forTokenCostsV0provides consistent accessors that correctly clone the cost values. This ensures that callers can't accidentally modify the internal state.
56-99: Consistent setter implementationThe
TokenCostSettersV0trait implementation provides a clean and consistent way to modify token costs for various document operations. The setter methods follow a good pattern where costs can be set or cleared (by passing None).packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs (4)
1-23: Comprehensive imports for document type accessorsThe imports cover all required components for document type handling, including basic data structures, token costs, and conditional validation features.
24-119: Well-structured V0 getter implementation for backward compatibilityThe implementation of
DocumentTypeV0GettersforDocumentTypeV1ensures backward compatibility by exposing V0 methods, allowing code that previously worked with V0 document types to continue working with V1 types.
121-125: Simple data contract ID setter implementationThe
DocumentTypeV0Settersimplementation provides a clean way to update the data contract ID in a V1 document type.
127-151: Well-implemented token cost accessors for V1 functionalityThe
DocumentTypeV1Gettersimplementation properly delegates to the token costs component for retrieving token costs associated with various document operations. This design follows good separation of concerns by delegating to specialized components.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/replacement.rs (1)
1932-2097: Comprehensive test for document replacement with token requirementsThis test case thoroughly validates the document replacement functionality with token requirements. It:
- Sets up the platform environment and creates identities
- Creates a token contract and verifies initial token supply
- Adds tokens to the creator's identity
- Creates and modifies a document
- Processes batch transitions for creation and replacement
- Verifies token balance after replacement to confirm tokens were spent
The test provides good coverage for the token cost functionality introduced in this PR.
packages/rs-dpp/src/data_contract/document_type/v0/accessors.rs (4)
1-3: Updated imports to include V0 settersThe imports now include both
DocumentTypeV0GettersandDocumentTypeV0Setterstraits, which aligns with the implementation in this file.
12-14: Conditional import for validation featuresThe
StatelessJsonSchemaLazyValidatoris conditionally imported based on the "validation" feature flag, following good practices for optional feature handling.
112-116: Feature-gated validator accessorThe
json_schema_validator_refmethod is properly feature-gated with the "validation" flag, ensuring it's only available when validation features are enabled. This method provides safe access to the JSON schema validator.
118-122: Data contract ID setter implementationThe implementation of
DocumentTypeV0SettersforDocumentTypeV0provides a straightforward way to update the data contract ID. This maintains consistency with the V1 implementation and follows the same pattern.packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_delete_transition.rs (2)
3-3: New TokenOperation import and related types added for document deletion token costs.The imports now include TokenOperation and TokenOperationType to support token burn operations during document deletion.
Also applies to: 15-15
38-65: Token burn operation properly integrated into document deletion.The implementation now handles token costs for document deletion by:
- Retrieving the document deletion token cost from the base
- Creating a mutable operations vector
- Conditionally adding a TokenBurn operation when a token cost is present
- Only burning tokens from the document owner's balance
This approach ensures backward compatibility while adding the new token requirement functionality.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/transfer.rs (1)
1019-1254: Comprehensive test for document transfer with token requirement.This test thoroughly validates the token cost functionality for document transfers by:
- Setting up identities and token contracts
- Verifying initial token supply and distribution
- Creating a document that requires a token for transfer
- Executing the transfer and verifying ownership changes
- Checking that the correct token amount was burned from the sender's balance
The test provides good coverage for the new token requirement feature during document transfers.
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_purchase_transition.rs (2)
3-3: New TokenOperation import and related types added for document purchase token costs.The imports now include TokenOperation and TokenOperationType to support token burn operations during document purchases.
Also applies to: 16-16
40-88: Token burn operation properly integrated into document purchase.The implementation now handles token costs for document purchases by:
- Retrieving the document purchase token cost from the base
- Creating a mutable operations vector that includes the necessary identity and document operations
- Conditionally adding a TokenBurn operation when a token cost is present
- Burning tokens only from the document buyer's balance
This implementation ensures that token costs are properly accounted for during document purchases while maintaining backward compatibility.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/deletion.rs (3)
5-5: Added import for token contract creation utility.The import is necessary for the new tests that require token contracts.
747-913: Well-structured test for document deletion with token requirement.This test thoroughly validates the token cost functionality for document deletion by:
- Setting up identities and token contracts
- Adding tokens to the buyer's identity
- Creating a document that requires tokens
- Verifying token balance changes after document creation
- Deleting the document and confirming successful execution
- Verifying that the correct token amount was burned from the owner's balance during deletion
The test provides good coverage for the new token requirement feature.
915-1085: Important negative test case for insufficient token balance.This test is crucial for validating error handling when attempting to delete a document without sufficient token balance. It:
- Sets up a scenario where the user has gold tokens but no gas tokens
- Creates a document (using gold tokens)
- Attempts to delete the document (requiring gas tokens)
- Verifies that the deletion fails with the correct error (IdentityDoesNotHaveEnoughTokenBalanceError)
- Confirms that token balances remain unchanged after the failed operation
This test ensures the system properly rejects operations when token requirements aren't met.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (6)
41-41: Added appropriate import for V1 contract getters.The import of
DataContractV1Gettersis necessary for accessing token-related functionality in the document creation tests. This is directly related to the new token payment features being tested.
267-270: Simplified error pattern matching.The code now uses
PaidConsensusErrordirectly instead ofStateTransitionExecutionResult::PaidConsensusError. This makes the error handling code more concise and readable without changing the functionality.
1758-1764: Simplified error pattern matching for document contest ID error.Similar to the previous change, this updates the error handling pattern for the document contest case to be more direct.
2146-2149: Improved error extraction pattern.The updated error handling pattern uses a cleaner
let...elsepattern for extracting the consensus error, improving readability.
2444-2563: Comprehensive test for successful token-paid document creation.This test thoroughly verifies the token payment workflow for document creation:
- Sets up a contract with token configuration
- Adds tokens to a buyer identity
- Creates a document that requires token payment
- Verifies successful execution
- Confirms the correct token balance deduction (15 → 5, implying 10 tokens spent)
This test is essential for validating the core functionality of the token requirement feature.
2565-2690: Thorough test for insufficient token balance case.This test properly validates the error handling when a user attempts to create a document without sufficient token balance:
- Sets up with only 8 tokens when 10 are required
- Verifies the appropriate error is returned
- Confirms token balance remains unchanged
Good negative test case that ensures proper error handling.
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_replace_transition.rs (6)
3-3: Updated import to include TokenOperation.Added TokenOperation to the existing import statement to support token burn operations.
17-17: Added import for TokenOperationType enum.This import is necessary for specifying the token burn operation type.
38-38: Added token cost retrieval from document transition.Retrieves the optional token cost information from the document base transition, which will be used to determine if a token burn operation is needed.
48-65: Changed operation collection to mutable vector.Modified the return structure from a direct vector to a mutable vector to allow adding the token operation conditionally. This is a good approach that keeps the code clean while allowing for the conditional addition.
67-73: Added conditional token burn operation.This is the key implementation for the token requirement feature. When a token cost is specified, it adds a TokenBurn operation with:
- The token ID to burn
- The identity that holds the balance
- The amount to burn
The conditional structure ensures token operations are only added when necessary.
75-75: Updated return statement for modified operations collection.Simple but necessary change to return the ops vector that may contain the additional token operation.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (1)
430-463: Utility function for token management testsThe
add_tokens_to_identityfunction is a well-structured test utility that handles both sides of token balance updates - adding to an identity's balance and updating the token's total supply. This function follows the same pattern as other test utility functions in the file and will be useful for testing token-related functionality.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_purchase_transition_action/state_v0/mod.rs (1)
13-48: Good integration of base validation for purchase transitions.Introducing
DocumentBaseTransitionActionValidationand adding theblock_infoandexecution_contextparameters ensures the purchase transitions undergo the required base validation. The logic to early-return on invalid results is correct. This design also keeps the code consistent with other transition actions.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_transfer_transition_action/state_v0/mod.rs (1)
13-48: Validation flow aligns well with the base transition approach.Similar to the purchase transitions, reusing the base validation mechanism here improves consistency and keeps the transfer logic DRY. The early return when validation fails is a clean solution for handling errors. The added parameters (
block_infoandexecution_context) are used appropriately in thevalidate_state_v0()method.packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (1)
1-59: Unused import warnings appear to be false positives.Static analysis indicates that
MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH,MAX_INDEXED_STRING_PROPERTY_LENGTH,NOT_ALLOWED_SYSTEM_PROPERTIES, andSYSTEM_PROPERTIESmay be unused, but they are actually referenced later in the code (e.g., lines 414, 462, 482). Similarly,DocumentPropertyTypeis used for type checks at line 443. These warnings can be safely ignored or suppressed, as they do not represent actual unused imports.🧰 Tools
🪛 GitHub Check: Rust packages (dash-sdk) / Linting
[warning] 36-36:
warning: unused imports:MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH,MAX_INDEXED_STRING_PROPERTY_LENGTH,NOT_ALLOWED_SYSTEM_PROPERTIES, andSYSTEM_PROPERTIES
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:36:42
|
36 | insert_values, insert_values_nested, MAX_INDEXED_BYTE_ARRAY_PROPERTY_LENGTH,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
37 | MAX_INDEXED_STRING_PROPERTY_LENGTH, NOT_ALLOWED_SYSTEM_PROPERTIES, SYSTEM_PROPERTIES,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
[warning] 11-11:
warning: unused import:DocumentPropertyType
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:11:71
|
11 | use crate::data_contract::document_type::property::{DocumentProperty, DocumentPropertyType};
| ^^^^^^^^^^^^^^^^^^^^packages/rs-dpp/src/data_contract/document_type/v1/random_document_type.rs (2)
1-8: No issues with the new imports.These imports look correct and are consistent with the crate structure.
25-39: Invalid random document type method is well-documented.This wrapper around the v0 version is clear and useful for generating invalid test cases. Good job documenting its purpose. If you foresee more invalid scenarios, consider expanding test coverage.
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs (5)
16-18: Imports for validation look fine.These are conditionally compiled (
#[cfg(feature = "validation")]) which helps keep dependencies minimal. No further concerns here.
40-40: Import oftry_from_schemais aligned with new refactor.This import ensures the nested calls to
try_from_schema::insert_valuesare recognized.
82-82: Investigate error dropping under non-validation mode.When
validationis disabled, an error is constructed but silently discarded. This may lead to unexpected outcomes. Consider returning or logging the error explicitly if the code path is not truly safe to ignore.
245-256: Nested calls totry_from_schemasubroutines are organized.The approach clarifies property handling at different document nesting levels. Good job modularizing these calls.
596-596: Tests provide adequate coverage fortry_from_schema.Your test methods verify name constraints and schema validity. This thorough coverage is commendable.
Also applies to: 627-627, 669-669, 711-711, 737-737
packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (1)
4-47: Comprehensive and well-documented getters for token costs.
The trait is clearly structured, and the doc comments provide concise explanations for each method. This should greatly improve maintainability.packages/rs-dpp/src/data_contract/document_type/methods/mod.rs (2)
21-24: Clarify the use of random storage ID.
unique_id_for_storage()currently returns a random value. If the ID must be deterministic or reproducible across environments, consider an alternative approach. Otherwise, confirm that this randomness is acceptable and tested in higher-level logic.
50-55: Confirm the decision to return only the first property in top-level indices.
top_level_indicesreturns the first property of each index. If an index has multiple properties, they are excluded. Ensure that’s the intended behavior and not a partial approach.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_delete_transition_action/state_v0/mod.rs (1)
20-20: New import for base action validation
This import supports modular and consistent validation by leveraging the shared base transition validation logic.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_update_price_transition_action/state_v0/mod.rs (2)
13-13: Addition ofDocumentBaseTransitionActionValidationimport
This expands the reuse of the base transition validation logic, promoting consistency and maintainability across document actions.
37-48: Base validation call
Invokingself.base().validate_state(...)and returning early when invalid ensures proper short-circuiting. This approach is aligned with best practices for layered validation and error handling.packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/mod.rs (6)
3-8: Introduction ofDocumentTypeV1
These imports facilitate the new versioning approach, allowing for separate handling of version 0 and version 1 document types. This is a solid step toward more extensible schema handling.
11-12: IndexMap for schema parsing
UsingIndexMaphelps preserve insertion order when processing document properties. The approach is consistent with other schema parsing methods in this codebase.
15-15: Utilizing BTree collections
EmployingBTreeMapandBTreeSetis beneficial for maintaining sorted sets and maps, yielding consistent iteration order and performance.
20-36: Introduced system property constants
The addition ofNOT_ALLOWED_SYSTEM_PROPERTIESandSYSTEM_PROPERTIESclarifies permissible fields. Double-check that these lists accurately reflect the platform’s constraints.
56-67: Graceful handling for unknown versions
The match statement properly routes to version 0 or 1, returning an error on encountering an unexpected version. This robust error handling helps prevent accidental misuse.
87-157:insert_valuesfunction complexity
While this function addresses nested schema resolution and property insertion, its size and nested logic may hamper clarity. Splitting the branching logic into smaller helpers can improve readability.
[suggest_essential_refactor, offer_assistance]
Do you want me to provide a possible refactoring of nested loops and conditionals to simplify future maintenance?packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_replace_transition_action/state_v0/mod.rs (3)
13-13: New import usage looks appropriate.This newly introduced import for
DocumentBaseTransitionActionValidationcleanly integrates with the subsequent validation calls.
32-33: Method signature update is consistent.Referencing
block_infoandexecution_contextaligns with the new usage in the validation flow, ensuring proper handling of relevant execution parameters.
37-48: Early return on validation failure is well-structured.Calling
self.base().validate_state(...)followed by a quick exit when invalid is a clean approach that prevents unnecessary computation and ensures clarity in the validation logic.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/transformer.rs (3)
3-5: New imports support token cost management.These imports are necessary for handling token amounts, positions, and document types within the new transition logic.
16-16: Additional parameter introduced for token costs.The
get_token_costclosure provides a flexible mechanism to retrieve token-related data, enhancing extensibility for future token logic integrations.
34-38: Borrowed transition approach is consistent with existing patterns.Passing
get_token_costfollows the same design used for base transition handling, ensuring uniformity across code paths.packages/rs-dpp/src/data_contract/document_type/v1/mod.rs (6)
1-19: Imports are well-organized.The selected crates and modules neatly support the newly introduced versioned document type functionalities.
20-25: Feature flags and module structure are cleanly separated.The conditional compilation for validation and random document generation follows standard Rust practices, ensuring modularity without unnecessary bloat.
26-68: Struct fields and visibility levels seem suitable.All fields appear logically placed, with clear naming and appropriate scoping. This design supports comprehensive document management features (e.g., history, mutability, deletion).
70-72: Trait implementation is minimal and coherent.
DocumentTypeV1implements the required methods fromDocumentTypeBasicMethodsandDocumentTypeV0Methodswith no redundancies evident.
74-79: Setter method usage is straightforward.The
set_data_contract_idmethod is concise and clearly addresses the need for updating the contract ID in-place.
81-110: Conversion logic covers all relevant fields.Copying fields from
DocumentTypeV0and assigning a default fortoken_costsis consistent with the introduction of these new costs in V1. No issues found with field-to-field mapping.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/state_v0/mod.rs (1)
27-73: Consider potential race conditions for token balance checkingFetching the identity's token balance and proceeding with a token cost operation could be susceptible to concurrency issues if multiple transitions attempt to spend from the same identity in parallel. Ensure that either there's a preceding lock or a subsequent re-check to confirm the identity's balance hasn't been spent in the meantime. Alternatively, confirm that your consensus rules or execution environment ensures sequential processing to eliminate this scenario.
Would you like a script that scans for concurrency or locking mechanisms for token cost updates in the codebase?
packages/rs-dpp/src/data_contract/document_type/mod.rs (1)
97-125: Check for backward compatibilityIncluding logic for
V1within the existingprefunded_voting_balances_for_documentmethod could lead to unexpected results if older system components only expectV0behavior. Ensure that all relevant code paths (client or server) can handleV1gracefully.Would you like me to provide a script to search for references to
prefunded_voting_balances_for_documentacross the codebase to ensure it’s handled properly?packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/v0/transformer.rs (3)
3-3: Import usage looks appropriate.
The newly added import referencesDocumentTypeV1Gettersfor token cost retrieval, aligning with the new cost-based functionality. No issues spotted.
21-21: Verify token cost retrieval logic.
Ensure that the closure captures the correct token cost fromdocument_type.document_deletion_token_cost(). Consider adding coverage for scenarios where no cost is set or returned.
36-38: Consistent application of token cost retrieval.
The closure usage parallels line 21, ensuring deletion cost retrieval in the borrowed transition scenario. Looks fine.packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (2)
4-23: Sufficiently detailed getter trait.
TheTokenCostGettersV0trait comprehensively exposes optional token cost values for multiple operations. The approach is consistent with the existing design, and documentation is clear.
25-62: Straightforward setter trait.
TheTokenCostSettersV0trait provides clear methods for adjusting each token cost, matching the getters' structure. No concurrency or security concerns found.packages/rs-dpp/src/data_contract/document_type/methods/versioned_methods.rs (2)
1-29: Logical imports and trait scaffolding.
Imports and foundational traits are well-organized, supporting versioned document operations. The approach for version handling is consistent with the existing multi-version strategy.
345-590: Robust set of helper methods for document management.
Methods for vote polling, indexing, sizes, prefunded balances, and serialization/deserialization are well-structured. The overall implementation is consistent with versioned approach. No critical issues found.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/transformer.rs (5)
27-37: Validate handling ofNonetoken cost.
Whenget_token_costreturnsNone, the code currently setstoken_costtoNone. Ensure this scenario has been tested or verified for correctness, since it implies a document type that does not incur tokens.
43-43: Inclusion oftoken_costin return structure looks fine.
No issues found. Integration with the rest of the transition data appears consistent.
51-52: Mirror approach for borrowed transitions.
Passingget_token_costas a parameter keeps behavior consistent with the non-borrowed version. Good job ensuring parallelism.
59-69: Reused logic ensures consistent token ID calculation.
The usage ofcalculate_token_idand closure mapping is well-aligned with the earlier function for a borrowed base transition. This reuse helps maintain consistency across the codebase.
75-75: Inclusion oftoken_costfinalizes the struct well.
Data contract references and token cost logic are integrated coherently.packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs (7)
2-2: New module imports for v1 logic.
Bringing inmod v1and the related imports (e.g.,TokenAmount,StatelessJsonSchemaLazyValidator,TokenContractPosition) is a clean, forward-compatible approach. This sets the stage for version-specific expansions without overloading the v0 code.Also applies to: 11-16, 23-23
29-177: Extended getters for DocumentType v1.
All these match arms passing through toDocumentType::V1(v1)are consistent with the existing v0 pattern. This ensures that v1 logic remains backward-compatible while providing the new functionality.
180-187: Conditional validator references and data contract ID setters.
The newly added v1 paths forjson_schema_validator_refandset_data_contract_idfollow the same pattern as v0. Good job keeping the API uniform.Also applies to: 189-196
202-350: Reflected v1 functionality for document type references.
The expansions forDocumentTypeRefandDocumentTypeMutRefmaintain the same thorough coverage asDocumentTypeitself, allowing code that depends on references to interact with v1 seamlessly.
353-360: Validation gating and setter bridging.
The#[cfg(feature = "validation")]gating and bridging setters for v1 are well-structured. They avoid any confusion that could arise from optional features.Also applies to: 525-531
534-620: NewDocumentTypeV1Gettershandle token costs.
Adding thesedocument_*_token_costmethods extends the domain model for token-based operations. This is a solid approach for versioned logic; returningNonefor v0 is especially clear.
622-664: Robust coverage for references and mutable references of v1 token cost.
The reference-based implementations mirror the main trait, ensuring consistent behavior across all usage contexts.packages/rs-dpp/src/data_contract/document_type/random_document.rs (9)
2-5: Appropriate imports for random document generation.
IntroducingDocumentTypeV0GettersandDocumentTypeV0Methodsclarifies that complex randomization depends on existing property introspection and document structure logic.
7-10: Extended property names and RNG usage.
Including property names likeCREATED_AT, etc., and seeding withStdRngis straightforward for generating consistent random documents across tests.Also applies to: 17-19
41-41: Trait constraints forCreateRandomDocument.
CombiningDocumentTypeV0Getters+DocumentTypeV0Methodsin the trait ensures each implementor can access essential metadata for property-based randomization.
59-65: Default random document generation pathway.
The approach of optionally seeding the RNG or usingfrom_entropyis great for reproducible test scenarios vs. nondeterministic runs. The fallback to fill any optional fields is a helpful default.Also applies to: 82-97
117-123: Bulk random documents creation.
Accumulating multiple documents with consistent random generation logic fosters reuse. This code is well structured for testing large data sets.Also applies to: 143-149
174-186:random_document_with_identifier_and_entropyspecialization.
This method provides a more precise handle on the random generation process, crucial for scenarios needing specificowner_idor entropy inputs.
216-358: Detailed param-based random document generation.
Filling properties selectively byDocumentFieldFillTypeandDocumentFieldFillSizeis well-thought-out. The usage of system time and block heights for required fields is consistent with real-world data simulation.
390-417: Batch random documents with parameterization.
Good error handling for insufficient identities and clean logic for generating a list of(Document, Identity, Bytes32)tuples. This pattern is beneficial for advanced tests or benchmarks where we match documents to owners.
421-424: Separate implementations forDocumentTypeandDocumentTypeRef.
Both are valid use cases, ensuring no unintentional limitation on references.
packages/rs-drive/src/util/operations/apply_batch_low_level_drive_operations/v0/mod.rs
Outdated
Show resolved
Hide resolved
packages/rs-drive/src/drive/tokens/system/add_to_token_total_supply/mod.rs
Show resolved
Hide resolved
packages/rs-drive/src/drive/tokens/system/add_to_token_total_supply/v0/mod.rs
Show resolved
Hide resolved
packages/rs-drive/src/drive/tokens/system/remove_from_token_total_supply/v0/mod.rs
Show resolved
Hide resolved
...abci/tests/supporting_files/contract/crypto-card-game/crypto-card-game-in-game-currency.json
Show resolved
Hide resolved
QuantumExplorer
changed the title
chore: update to latest dash core 37 (#2483) feat(platform)!: token advanced distribution and updates (#2471) fix: token history contract (#2474) Co-authored-by: Ivan Shumkov <[email protected]> Co-authored-by: QuantumExplorer <[email protected]> fix(drive): using new rust dash core methods for reversed quorum hash to maintain backwards compatibility (#2489) feat: more granular integer document property types (#2455) Co-authored-by: Quantum Explorer <[email protected]> docs: update comment for data contract code range (#2476) feat: validate token name localizations (#2468) feat(sdk): get identity by non-unique keys build(deps): update grovedb to current develop test: test identity by non-unique pubkey hashes fix(sdk): dash core client fails to get quorum chore: minor fixes test(drive-abci): identity by non-unique pubkey start after chore: minor changes to verify feat(sdk): token and group queries (#2449) chore: revert limit 1 => limit none chore: add non-unique key to test identities test(sdk): test vectors for test_fetch_identity_by_non_unique_public_keys fix(platform)!: token distribution fixes and tests (#2494) chore(platform): bump to version 2.0.0-dev.1 (#2495) test: update assertion fix(sdk): make some things public (#2496) feat(platform): require token for document actions (#2498) fix: data contract proof doesn't work with new auto fields (#2501)
chore: update to latest dash core 37 (#2483) feat(platform)!: token advanced distribution and updates (#2471) fix: token history contract (#2474) Co-authored-by: Ivan Shumkov <[email protected]> Co-authored-by: QuantumExplorer <[email protected]> fix(drive): using new rust dash core methods for reversed quorum hash to maintain backwards compatibility (#2489) feat: more granular integer document property types (#2455) Co-authored-by: Quantum Explorer <[email protected]> docs: update comment for data contract code range (#2476) feat: validate token name localizations (#2468) feat(sdk): get identity by non-unique keys build(deps): update grovedb to current develop test: test identity by non-unique pubkey hashes fix(sdk): dash core client fails to get quorum chore: minor fixes test(drive-abci): identity by non-unique pubkey start after chore: minor changes to verify feat(sdk): token and group queries (#2449) chore: revert limit 1 => limit none chore: add non-unique key to test identities test(sdk): test vectors for test_fetch_identity_by_non_unique_public_keys fix(platform)!: token distribution fixes and tests (#2494) chore(platform): bump to version 2.0.0-dev.1 (#2495) test: update assertion fix(sdk): make some things public (#2496) feat(platform): require token for document actions (#2498) fix: data contract proof doesn't work with new auto fields (#2501)
3 participants
Summary by CodeRabbit
Checklist:
For repository code-owners and collaborators only