feat(platform)!: token payment info #2517
Conversation
WalkthroughThis PR introduces new properties, types, and methods to enhance token cost handling in document transitions. The JSON schemas now include structured definitions for document action token costs. Accessor and setter methods for document types have been updated to use the new Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant F as Document Factory
participant S as State Transition Processor
participant V as State Validator
participant T as Token Payment Processor
C->>F: Create document transition request with TokenPaymentInfo
F->>S: Generate document transition\n(includes DocumentActionTokenCost)
S->>T: Process token cost (check effect)
alt Transfer Token
T->>S: Return TokenTransfer operation
else Burn Token
T->>S: Return TokenBurn operation
end
S->>V: Validate transition and fees
V-->>S: Return ConsensusValidationResult
S->>F: Wrap as BatchedTransitionAction
F-->>C: Return transition action & fee result
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🪧 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: 4
🔭 Outside diff range comments (1)
packages/rs-dpp/src/tests/fixtures/get_document_transitions_fixture.rs (1)
25-37: 💡 Verification agent🧩 Analysis chain
Verify that dependent test code has been updated.
While the function signature has been updated correctly, we should ensure that all test cases calling this function have been updated to provide the required TokenPaymentInfo parameter.
🏁 Script executed:
#!/bin/bash # Find all calls to get_batched_transitions_fixture to check if they've been updated echo "Searching for calls to get_batched_transitions_fixture:" rg "get_batched_transitions_fixture\(" --type rust -A 2 -B 2Length of output: 4048
Action Required: Update All Test Calls to Include the TokenPaymentInfo Parameter
The fixture function’s signature now requires an additional TokenPaymentInfo parameter. However, our search indicates that several test cases calling
get_batched_transitions_fixture(for example, in the following locations) have not been updated accordingly and are still passing only the existing arguments:
- packages/rs-dpp/src/state_transition/serialization.rs
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dpns/v0/mod.rs
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dashpay/v0/mod.rs
Please update these calls so they provide the required TokenPaymentInfo parameter along with the other arguments.
🧹 Nitpick comments (23)
packages/rs-dpp/src/document/extended_document/accessors.rs (1)
156-161: Fix the documentation comment for token_payment_info method.The documentation comment for this method incorrectly states "Returns a reference to the actual document object containing the data", which does not match the method's purpose.
- /// Returns a reference to the actual document object containing the data. + /// Returns the token payment information associated with the document, if present. pub fn token_payment_info(&self) -> Option<TokenPaymentInfo> { match self { ExtendedDocument::V0(v0) => v0.token_payment_info, } }packages/rs-dpp/src/tokens/token_amount_on_contract_token.rs (1)
63-75: Inconsistent documentation comment for the effect field.The comment for the
effectfield incorrectly states "The amount" which was likely copied from thetoken_amountfield.- /// The amount + /// The action effect to apply when token is spent pub effect: DocumentActionTokenEffect,packages/rs-drive-abci/tests/supporting_files/contract/crypto-card-game/crypto-card-game-use-external-currency.json (1)
1-137: Schema design is clear—consider extending token costs for other transitionsThis newly introduced JSON schema correctly defines a card object and embeds token cost data for the “create” action (
"tokenCost": {"create": {...}}). If you plan on charging tokens for other transition actions (e.g.,"update"or"delete"), consider adding them here for future-proofing. Additionally, clarify whether"effect": 0aligns with the intended token effect logic, as expansions or changes later might benefit from an explicit enumeration.packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_document_action_token_effect_error.rs (1)
22-37: Constructor and getters appear sound
Providing a dedicatednewconstructor and clear getters is beneficial. Ensure that you handle potential edge cases whereallowed_valuesis empty or extremely large.Consider documenting in the doc comments any assumptions about the size or content of
allowed_values.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/mod.rs (1)
200-280: Consolidate repeated timestamp and field checks
Within this block, several lines check if fields likerequires_created_at,requires_updated_at, etc., are required, then assign the same block info values. This is functionally correct but somewhat repetitive. Consider consolidating this repeated logic into a helper function or method returning a small struct of required fields. It will improve readability and maintainability.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/advanced_structure/v0/mod.rs (1)
90-94: Refactored token position validation with enumerateThe token position validation has been improved using
enumerate()to track positions automatically, reducing the chance of off-by-one errors. The code now explicitly casts the index toTokenContractPositionfor type safety.Consider adding a comment explaining why the cast to
TokenContractPositionis safe in this context, especially if there are constraints on the maximum number of tokens that can be defined in a contract.packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_gas_fees_paid_by_error.rs (1)
25-46: Consider returning a reference to avoid copying.Your
allowed_values()method currently returns a newVec<u8>, which might be unnecessary if this list is large. Returning a slice (e.g.,&[u8]) could avoid an extra copy, improving efficiency:-pub fn allowed_values(&self) -> Vec<u8> { - self.allowed_values.clone() +pub fn allowed_values(&self) -> &[u8] { + &self.allowed_values }packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs (2)
9-19: Structure definition looks good, but consider using borrowed types where appropriate.The error structure is well-defined with all necessary fields to identify token mismatches. However, for better performance, consider using references instead of owned types for immutable fields like identifiers.
pub struct IdentityTryingToPayWithWrongTokenError { - expected_contract_id: Option<Identifier>, + expected_contract_id: Option<Identifier>, // This is fine as Option expected_token_contract_position: TokenContractPosition, - expected_token_id: Identifier, + expected_token_id: Identifier, // Keep as owned since we need to return references - actual_contract_id: Option<Identifier>, + actual_contract_id: Option<Identifier>, // This is fine as Option actual_token_contract_position: TokenContractPosition, - actual_token_id: Identifier, + actual_token_id: Identifier, // Keep as owned since we need to return references }
41-63: Getter methods are correct but could avoid cloning.The getter methods provide access to the error's internal data, but some methods unnecessarily clone data. For better performance, consider returning references where appropriate.
pub fn expected_contract_id(&self) -> Option<Identifier> { - self.expected_contract_id.clone() + self.expected_contract_id } // Similar change for actual_contract_id pub fn actual_contract_id(&self) -> Option<Identifier> { - self.actual_contract_id.clone() + self.actual_contract_id }packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (1)
2487-2492: Consider adding a comment explaining token burning functionality.The function
create_card_game_internal_token_contract_with_owner_identity_burn_tokenscreates a contract with token burning capabilities, but the implementation details are not obvious from the name alone. Consider adding a comment explaining how tokens are configured to be burned rather than transferred.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs (6)
92-92: Add doc comments for the new parameter
The newly addeduser_fee_increaseparameter would benefit from a brief explanation of its purpose and usage in the function’s documentation.
106-106: Explain theuser_fee_increaseparameter
Similarly, please provide a short doc comment describing how this parameter affects the logic.
148-148: Document the newuser_fee_increaseparameter
Adding a concise explanation for this parameter will help maintain clarity for future maintainers.
356-356: Add doc comment foruser_fee_increase
A short explanation documenting its effect would provide clarity.
411-411: Clarify usage ofuser_fee_increase
Documenting how this parameter is intended to influence the state transition would be helpful.
478-478: Include a quick note foruser_fee_increase
A small inline doc or function-level doc would improve maintainability.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs (1)
28-41: Add doc comments for newly introduced parameters
Theowner_idanduser_fee_increaseparameters would benefit from brief doc strings detailing their usage and expected values.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs (2)
698-801: Thorough test for NFT purchase burn scenario
This test is quite detailed. Consider verifying final token balances post-burn to further confirm correctness.
803-908: Internal token transfer test
Implementation looks good. Adding final token balance checks might increase coverage.packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (2)
8-10: Updated return type documentationThe documentation has been properly updated to reflect the change from tuple to structured type, but there's a slight inconsistency in naming.
There's a small inconsistency in the documentation - it references
TokenActionCostinstead ofDocumentActionTokenCost. Consider updating for consistency:- /// - `Some(TokenActionCost)` if a creation cost exists. + /// - `Some(DocumentActionTokenCost)` if a creation cost exists.
15-16: Consistent return type documentation updatesThe documentation for all token cost getter methods has been consistently updated, which is good, but they all have the same naming inconsistency.
All documentation comments for the getter methods use
TokenActionCostinstead ofDocumentActionTokenCost. Consider updating all instances for consistency with the actual return type.Also applies to: 22-23, 29-30, 36-37, 43-44
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/v0/mod.rs (2)
27-43: Added token_payment_info parameter to new_document_creation_transition_from_documentThe method signature is updated to include token payment information, but lacks documentation for the new parameter.
Consider adding documentation for the new
token_payment_infoparameter to explain its purpose, particularly since this is a trait interface that implementers will need to understand.
44-59: Added token_payment_info parameter to remaining document transition methodsAll document transition methods in the trait have been consistently updated to include the token_payment_info parameter, but none have documentation explaining this parameter.
Consider adding documentation for the new
token_payment_infoparameter across all trait methods to improve developer understanding of how token payments should be handled in each document operation context.Also applies to: 60-75, 76-92, 93-109, 110-127
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (107)
packages/rs-dpp/schema/meta_schemas/document/v0/document-meta.json(2 hunks)packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs(5 hunks)packages/rs-dpp/src/data_contract/document_type/accessors/v0/mod.rs(1 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/v1/mod.rs(3 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(2 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(2 hunks)packages/rs-dpp/src/data_contract/document_type/v0/mod.rs(0 hunks)packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs(2 hunks)packages/rs-dpp/src/data_contract/document_type/v1/mod.rs(2 hunks)packages/rs-dpp/src/document/document_factory/mod.rs(2 hunks)packages/rs-dpp/src/document/document_factory/v0/mod.rs(13 hunks)packages/rs-dpp/src/document/extended_document/accessors.rs(2 hunks)packages/rs-dpp/src/document/extended_document/fields.rs(1 hunks)packages/rs-dpp/src/document/extended_document/mod.rs(3 hunks)packages/rs-dpp/src/document/extended_document/serde_serialize.rs(1 hunks)packages/rs-dpp/src/document/extended_document/v0/mod.rs(13 hunks)packages/rs-dpp/src/document/extended_document/v0/serialize.rs(1 hunks)packages/rs-dpp/src/document/serialization_traits/platform_serialization_conversion/mod.rs(1 hunks)packages/rs-dpp/src/document/specialized_document_factory/mod.rs(2 hunks)packages/rs-dpp/src/document/specialized_document_factory/v0/mod.rs(12 hunks)packages/rs-dpp/src/errors/consensus/basic/basic_error.rs(2 hunks)packages/rs-dpp/src/errors/consensus/basic/data_contract/mod.rs(2 hunks)packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs(1 hunks)packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_document_action_token_effect_error.rs(1 hunks)packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_gas_fees_paid_by_error.rs(1 hunks)packages/rs-dpp/src/errors/consensus/codes.rs(2 hunks)packages/rs-dpp/src/errors/consensus/state/state_error.rs(2 hunks)packages/rs-dpp/src/errors/consensus/state/token/identity_has_not_agreed_to_pay_required_token_amount_error.rs(1 hunks)packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs(1 hunks)packages/rs-dpp/src/errors/consensus/state/token/mod.rs(4 hunks)packages/rs-dpp/src/errors/consensus/state/token/required_token_payment_info_not_set_error.rs(1 hunks)packages/rs-dpp/src/errors/protocol_error.rs(1 hunks)packages/rs-dpp/src/state_transition/serialization.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/fields.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/mod.rs(3 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/mod.rs(3 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/v0_methods.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0_methods.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/mod.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/convertible.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/from_document.rs(3 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/from_document.rs(3 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/mod.rs(4 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/v0/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/v0/from_document.rs(3 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/v0/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/from_document.rs(3 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/v0/from_document.rs(3 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/v0/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/mod.rs(19 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/v0/mod.rs(7 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v0/v0_methods.rs(13 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs(13 hunks)packages/rs-dpp/src/tests/fixtures/get_document_transitions_fixture.rs(1 hunks)packages/rs-dpp/src/tokens/gas_fees_paid_by.rs(1 hunks)packages/rs-dpp/src/tokens/mod.rs(1 hunks)packages/rs-dpp/src/tokens/token_amount_on_contract_token.rs(1 hunks)packages/rs-dpp/src/tokens/token_payment_info/methods/mod.rs(1 hunks)packages/rs-dpp/src/tokens/token_payment_info/methods/v0/mod.rs(1 hunks)packages/rs-dpp/src/tokens/token_payment_info/mod.rs(1 hunks)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs(1 hunks)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs(1 hunks)packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/platform_events/block_processing_end_events/tests.rs(8 hunks)packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_list/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(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dashpay/v0/mod.rs(6 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dpns/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/withdrawals/v0/mod.rs(3 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs(31 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/deletion.rs(16 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/dpns.rs(12 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(33 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/replacement.rs(24 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/transfer.rs(13 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs(13 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/advanced_structure/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs(4 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs(14 hunks)packages/rs-drive-abci/tests/supporting_files/contract/crypto-card-game/crypto-card-game-in-game-currency-burn-tokens.json(1 hunks)packages/rs-drive-abci/tests/supporting_files/contract/crypto-card-game/crypto-card-game-use-external-currency.json(1 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_create_transition.rs(2 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(3 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_replace_transition.rs(3 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_transfer_transition.rs(3 hunks)packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_update_price_transition.rs(3 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(1 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(1 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.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/transformer.rs(1 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/v0/transformer.rs(1 hunks)
⛔ Files not processed due to max files limit (20)
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_purchase_transition_action/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_purchase_transition_action/v0/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/v0/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_transfer_transition_action/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_transfer_transition_action/v0/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_update_price_transition_action/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_update_price_transition_action/v0/transformer.rs
- packages/rs-drive/src/state_transition_action/batch/batched_transition/mod.rs
- packages/rs-drive/src/state_transition_action/system/bump_identity_data_contract_nonce_action/transformer.rs
- packages/rs-drive/src/state_transition_action/system/bump_identity_data_contract_nonce_action/v0/transformer.rs
- packages/rs-platform-value/src/btreemap_extensions/btreemap_removal_extensions.rs
- packages/rs-platform-version/src/version/dpp_versions/dpp_state_transition_serialization_versions/v2.rs
- packages/rs-sdk/src/platform/transition/purchase_document.rs
- packages/rs-sdk/src/platform/transition/put_document.rs
- packages/rs-sdk/src/platform/transition/transfer_document.rs
- packages/rs-sdk/src/platform/transition/update_price_of_document.rs
- packages/wasm-dpp/src/document/factory.rs
- packages/wasm-dpp/src/document/state_transition/batch_transition/document_transition/mod.rs
- packages/wasm-dpp/src/errors/consensus/consensus_error.rs
💤 Files with no reviewable changes (1)
- packages/rs-dpp/src/data_contract/document_type/v0/mod.rs
🧰 Additional context used
🧠 Learnings (1)
packages/rs-dpp/src/errors/consensus/state/token/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-03-29T14:43:50.133Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
🧬 Code Definitions (58)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/mod.rs (1)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (16)
execution(136-147)execution(149-205)execution(207-248)execution(250-306)execution(353-429)execution(431-464)execution(466-537)execution(539-553)execution(555-658)execution(660-747)execution(749-764)execution(766-837)execution(839-872)execution(875-909)execution(911-964)execution(1565-1746)
packages/rs-dpp/src/tokens/mod.rs (5)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (1)
gas_fees_paid_by(99-103)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (1)
gas_fees_paid_by(90-92)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (1)
gas_fees_paid_by(38-38)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/from_document.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/from_document.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/tests/fixtures/get_document_transitions_fixture.rs (4)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)packages/rs-dpp/src/document/specialized_document_factory/v0/mod.rs (1)
documents(262-292)packages/rs-dpp/src/document/document_factory/v0/mod.rs (1)
documents(254-284)
packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (1)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (11)
gas_fees_paid_by(90-92)payment_token_contract_id(53-55)payment_token_contract_id_ref(57-59)token_contract_position(61-63)minimum_token_cost(65-67)maximum_token_cost(69-71)set_payment_token_contract_id(74-76)set_token_contract_position(78-80)set_minimum_token_cost(82-84)set_maximum_token_cost(86-88)set_gas_fees_paid_by(94-96)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/withdrawals/v0/mod.rs (3)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (1)
gas_fees_paid_by(99-103)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (1)
gas_fees_paid_by(90-92)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (1)
gas_fees_paid_by(38-38)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs (5)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs (1)
from_document(12-46)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/from_document.rs (1)
from_document(12-36)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/v0/from_document.rs (1)
from_document(11-29)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/v0/from_document.rs (1)
from_document(13-38)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/v0/from_document.rs (1)
from_document(13-38)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/from_document.rs (7)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs (1)
from_document(12-46)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/from_document.rs (1)
from_document(11-45)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs (1)
from_document(12-44)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/from_document.rs (1)
from_document(11-43)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/v0/from_document.rs (1)
from_document(13-42)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/from_document.rs (1)
from_document(13-47)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/from_document.rs (1)
from_document(12-46)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dpns/v0/mod.rs (4)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs (1)
document_type(37-37)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/mod.rs (1)
document_type(35-40)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (1)
try_from_document_borrowed_create_transition_with_contract_lookup(18-39)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs (1)
try_from_document_borrowed_create_transition_with_contract_lookup(14-29)
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (4)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (2)
gas_fees_paid_by(99-103)token_contract_position(56-60)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (2)
gas_fees_paid_by(90-92)token_contract_position(61-63)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (2)
gas_fees_paid_by(38-38)token_contract_position(17-17)packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs (1)
new(23-33)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/mod.rs (1)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs (1)
token_cost(57-57)
packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_document_action_token_effect_error.rs (2)
packages/rs-dpp/src/errors/consensus/basic/basic_error.rs (1)
from(521-523)packages/rs-dpp/src/errors/protocol_error.rs (8)
from(296-298)from(302-304)from(308-310)from(314-316)from(320-322)from(326-328)from(332-334)from(338-340)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/from_document.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/v0/from_document.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/v0/from_document.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (1)
state_transition(9-22)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (8)
token_payment_info(10-10)token_payment_info(23-25)token_payment_info_ref(13-13)token_payment_info_ref(27-29)set_token_payment_info(16-16)set_token_payment_info(31-33)clear_token_payment_info(19-19)clear_token_payment_info(35-37)
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (2)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (1)
try_from(102-124)packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_gas_fees_paid_by_error.rs (1)
new(26-31)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (2)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (12)
gas_fees_paid_by(90-92)payment_token_contract_id(53-55)payment_token_contract_id_ref(57-59)token_contract_position(61-63)minimum_token_cost(65-67)maximum_token_cost(69-71)set_payment_token_contract_id(74-76)set_token_contract_position(78-80)set_minimum_token_cost(82-84)set_maximum_token_cost(86-88)set_gas_fees_paid_by(94-96)try_from(102-124)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (11)
gas_fees_paid_by(38-38)payment_token_contract_id(9-9)payment_token_contract_id_ref(14-14)token_contract_position(17-17)minimum_token_cost(20-20)maximum_token_cost(23-23)set_payment_token_contract_id(26-26)set_token_contract_position(29-29)set_minimum_token_cost(32-32)set_maximum_token_cost(35-35)set_gas_fees_paid_by(41-41)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/from_document.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/from_document.rs (6)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs (1)
from_document(12-46)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/from_document.rs (1)
from_document(11-45)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs (1)
from_document(12-44)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/from_document.rs (1)
from_document(11-43)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/from_document.rs (1)
from_document(13-47)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/v0/from_document.rs (1)
from_document(13-38)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/advanced_structure/v0/mod.rs (2)
packages/rs-dpp/src/document/extended_document/accessors.rs (1)
data_contract(164-168)packages/rs-dpp/src/tokens/token_payment_info/mod.rs (1)
token_contract_position(56-60)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/mod.rs (5)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (1)
state_transition(9-22)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (3)
token_payment_info(10-10)token_payment_info(23-25)identity_contract_nonce(73-75)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/mod.rs (1)
from_value_map_consume(65-79)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0_methods.rs (1)
identity_contract_nonce(64-69)
packages/rs-dpp/src/errors/consensus/state/token/required_token_payment_info_not_set_error.rs (3)
packages/rs-dpp/src/errors/consensus/state/token/identity_has_not_agreed_to_pay_required_token_amount_error.rs (4)
token_id(48-50)action(64-66)new(32-46)from(70-72)packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs (3)
action(51-53)new(23-33)from(73-75)packages/rs-dpp/src/errors/consensus/state/state_error.rs (1)
from(295-297)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (9)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (3)
token_payment_info(10-10)token_payment_info(23-25)identity_contract_nonce(73-75)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs (1)
from_document(12-46)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/from_document.rs (1)
from_document(12-36)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/v0/from_document.rs (1)
from_document(11-29)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/v0/from_document.rs (1)
from_document(13-42)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/v0/from_document.rs (1)
from_document(12-36)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/v0/from_document.rs (1)
from_document(13-38)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/v0/from_document.rs (1)
from_document(13-38)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/v0_methods.rs (2)
identity_contract_nonce(29-29)identity_contract_nonce(66-68)
packages/rs-dpp/src/document/specialized_document_factory/mod.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs (6)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (1)
state_transition(9-22)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (3)
token_payment_info(10-10)token_payment_info(23-25)identity_contract_nonce(73-75)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/from_document.rs (1)
from_document(12-36)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/v0/from_document.rs (1)
from_document(13-38)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/v0/from_document.rs (1)
from_document(13-38)
packages/rs-dpp/src/tokens/token_amount_on_contract_token.rs (1)
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (3)
from(26-32)try_from(38-50)try_from(56-67)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/mod.rs (3)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (1)
identity_contract_nonce(73-75)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/v0_methods.rs (2)
identity_contract_nonce(29-29)identity_contract_nonce(66-68)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0_methods.rs (1)
identity_contract_nonce(64-69)
packages/rs-dpp/src/document/document_factory/mod.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/v0_methods.rs (3)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs (1)
document_type_name_owned(45-45)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (1)
document_type_name_owned(53-55)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0_methods.rs (1)
document_type_name_owned(29-34)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/mod.rs (1)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (1)
state_transition(9-22)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dashpay/v0/mod.rs (1)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (1)
try_from_document_borrowed_create_transition_with_contract_lookup(18-39)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (2)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs (1)
try_from_document_borrowed_create_transition_with_contract_lookup(14-29)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs (1)
try_from_borrowed_document_create_transition_with_contract_lookup(26-156)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/v0/from_document.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/v0/from_document.rs (3)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs (1)
from_document(12-44)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/deletion.rs (1)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (19)
execution(136-147)execution(149-205)execution(207-248)execution(250-306)execution(353-429)execution(431-464)execution(466-537)execution(539-553)execution(555-658)execution(660-747)execution(749-764)execution(766-837)execution(839-872)execution(875-909)execution(911-964)execution(1565-1746)None(937-937)None(947-947)None(1298-1298)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0_methods.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (10)
set_id(45-47)id(41-43)document_type_name(49-51)document_type_name_owned(53-55)set_document_type_name(57-59)data_contract_id(61-63)data_contract_id_ref(65-67)set_data_contract_id(69-71)identity_contract_nonce(73-75)set_identity_contract_nonce(77-79)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs (5)
id(34-34)document_type_name(43-43)document_type_name_owned(45-45)data_contract_id(47-47)identity_contract_nonce(54-54)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/state_v0/mod.rs (2)
packages/rs-dpp/src/document/extended_document/v0/mod.rs (1)
owner_id(159-161)packages/rs-dpp/src/document/extended_document/accessors.rs (1)
owner_id(35-39)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (10)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (1)
state_transition(9-22)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (1)
gas_fees_paid_by(90-92)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (1)
gas_fees_paid_by(38-38)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs (1)
new_document_creation_transition_from_document(130-170)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/v0/mod.rs (1)
new_document_creation_transition_from_document(30-43)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/mod.rs (1)
default(51-53)packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (1)
document_creation_token_cost(10-10)packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (1)
document_creation_token_cost(6-6)packages/rs-dpp/src/data_contract/document_type/token_costs/v0/mod.rs (1)
document_creation_token_cost(30-32)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/transformer.rs (8)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (2)
gas_fees_paid_by(90-92)token_contract_position(61-63)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (2)
gas_fees_paid_by(38-38)token_contract_position(17-17)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (3)
token_payment_info(10-10)token_payment_info(23-25)data_contract_id(61-63)packages/rs-dpp/src/errors/consensus/state/token/identity_has_not_agreed_to_pay_required_token_amount_error.rs (2)
action(64-66)new(32-46)packages/rs-dpp/src/errors/consensus/state/token/required_token_payment_info_not_set_error.rs (2)
action(32-34)new(24-26)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0_methods.rs (1)
data_contract_id(43-48)packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs (1)
new(23-39)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs (3)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (1)
gas_fees_paid_by(99-103)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (1)
gas_fees_paid_by(90-92)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (1)
gas_fees_paid_by(38-38)
packages/rs-dpp/src/data_contract/document_type/v1/mod.rs (3)
packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (6)
set_document_creation_token_cost(54-54)set_document_replacement_token_cost(60-60)set_document_deletion_token_cost(66-66)set_document_transfer_token_cost(72-72)set_document_price_update_token_cost(78-78)set_document_purchase_token_cost(84-84)packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (6)
set_document_creation_token_cost(27-27)set_document_replacement_token_cost(30-30)set_document_deletion_token_cost(33-33)set_document_transfer_token_cost(36-36)set_document_price_update_token_cost(39-39)set_document_purchase_token_cost(42-42)packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs (6)
set_document_creation_token_cost(58-62)set_document_replacement_token_cost(64-68)set_document_deletion_token_cost(70-74)set_document_transfer_token_cost(76-80)set_document_price_update_token_cost(82-86)set_document_purchase_token_cost(88-92)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (5)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (2)
gas_fees_paid_by(99-103)token_contract_position(56-60)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (2)
gas_fees_paid_by(90-92)token_contract_position(61-63)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (2)
gas_fees_paid_by(38-38)token_contract_position(17-17)packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs (3)
data_contract_id(160-165)data_contract_id(377-382)data_contract_id(540-545)packages/rs-dpp/src/tokens/token_payment_info/methods/v0/mod.rs (1)
token_id(33-41)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (5)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (13)
gas_fees_paid_by(99-103)payment_token_contract_id(44-48)token_contract_position(56-60)minimum_token_cost(62-66)maximum_token_cost(68-72)payment_token_contract_id_ref(50-54)set_payment_token_contract_id(75-79)set_token_contract_position(81-85)set_minimum_token_cost(87-91)set_maximum_token_cost(93-97)set_gas_fees_paid_by(105-109)try_from(115-131)try_from(136-138)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (11)
gas_fees_paid_by(38-38)payment_token_contract_id(9-9)token_contract_position(17-17)minimum_token_cost(20-20)maximum_token_cost(23-23)payment_token_contract_id_ref(14-14)set_payment_token_contract_id(26-26)set_token_contract_position(29-29)set_minimum_token_cost(32-32)set_maximum_token_cost(35-35)set_gas_fees_paid_by(41-41)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (2)
try_from(38-50)try_from(56-67)packages/rs-dpp/src/tokens/token_amount_on_contract_token.rs (2)
try_from(32-43)try_from(49-60)
packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs (3)
packages/rs-dpp/src/data_contract/document_type/accessors/v0/mod.rs (1)
schema_mut(19-19)packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (6)
document_creation_token_cost(10-10)document_replacement_token_cost(17-17)document_deletion_token_cost(24-24)document_transfer_token_cost(31-31)document_update_price_token_cost(38-38)document_purchase_token_cost(45-45)packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (5)
document_creation_token_cost(6-6)document_replacement_token_cost(9-9)document_deletion_token_cost(12-12)document_transfer_token_cost(15-15)document_purchase_token_cost(21-21)
packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs (4)
packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs (21)
document_creation_token_cost(587-592)document_creation_token_cost(631-636)document_creation_token_cost(675-680)document_replacement_token_cost(594-599)document_replacement_token_cost(638-643)document_replacement_token_cost(682-687)document_deletion_token_cost(601-606)document_deletion_token_cost(645-650)document_deletion_token_cost(689-694)document_transfer_token_cost(608-613)document_transfer_token_cost(652-657)document_transfer_token_cost(696-701)document_purchase_token_cost(622-627)document_purchase_token_cost(666-671)document_purchase_token_cost(710-715)set_document_creation_token_cost(207-212)set_document_replacement_token_cost(214-219)set_document_deletion_token_cost(221-226)set_document_transfer_token_cost(228-233)set_document_price_update_token_cost(235-240)set_document_purchase_token_cost(242-247)packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (11)
document_creation_token_cost(10-10)document_replacement_token_cost(17-17)document_deletion_token_cost(24-24)document_transfer_token_cost(31-31)document_purchase_token_cost(45-45)set_document_creation_token_cost(54-54)set_document_replacement_token_cost(60-60)set_document_deletion_token_cost(66-66)set_document_transfer_token_cost(72-72)set_document_price_update_token_cost(78-78)set_document_purchase_token_cost(84-84)packages/rs-dpp/src/data_contract/document_type/token_costs/v0/mod.rs (12)
document_creation_token_cost(30-32)document_replacement_token_cost(34-36)document_deletion_token_cost(38-40)document_transfer_token_cost(42-44)document_price_update_token_cost(46-48)document_purchase_token_cost(50-52)set_document_creation_token_cost(57-59)set_document_replacement_token_cost(61-63)set_document_deletion_token_cost(65-67)set_document_transfer_token_cost(69-71)set_document_price_update_token_cost(73-75)set_document_purchase_token_cost(77-79)packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs (5)
document_creation_token_cost(133-135)document_replacement_token_cost(137-139)document_deletion_token_cost(141-143)document_transfer_token_cost(145-147)document_purchase_token_cost(153-155)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/dpns.rs (3)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (2)
None(309-309)None(3437-3437)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (3)
None(937-937)None(947-947)None(1298-1298)packages/rs-drive-abci/src/execution/platform_events/block_processing_end_events/tests.rs (6)
None(278-278)None(378-378)None(481-481)None(580-580)None(679-679)None(779-779)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/v0/mod.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v0/v0_methods.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/mod.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs (5)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (1)
try_from_document_borrowed_create_transition_with_contract_lookup(18-39)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs (1)
try_from_document_borrowed_create_transition_with_contract_lookup(14-29)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/transformer.rs (1)
try_from_borrowed_document_replace_transition(17-53)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_transfer_transition_action/transformer.rs (1)
try_from_borrowed_document_transfer_transition(16-42)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_purchase_transition_action/transformer.rs (1)
try_from_borrowed_document_purchase_transition(16-44)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs (2)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (1)
token_payment_info(6-11)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (2)
token_payment_info(10-10)token_payment_info(23-25)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs (3)
packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs (1)
new(23-33)packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs (1)
new(23-39)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (2)
None(309-309)None(3437-3437)
packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs (3)
packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs (6)
document_creation_token_cost(133-135)document_replacement_token_cost(137-139)document_deletion_token_cost(141-143)document_transfer_token_cost(145-147)document_update_price_token_cost(149-151)document_purchase_token_cost(153-155)packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (11)
set_document_creation_token_cost(27-27)set_document_replacement_token_cost(30-30)set_document_deletion_token_cost(33-33)set_document_transfer_token_cost(36-36)set_document_price_update_token_cost(39-39)set_document_purchase_token_cost(42-42)document_creation_token_cost(6-6)document_replacement_token_cost(9-9)document_deletion_token_cost(12-12)document_transfer_token_cost(15-15)document_purchase_token_cost(21-21)packages/rs-dpp/src/data_contract/document_type/v1/mod.rs (6)
set_document_creation_token_cost(78-80)set_document_replacement_token_cost(82-84)set_document_deletion_token_cost(86-88)set_document_transfer_token_cost(90-92)set_document_price_update_token_cost(94-96)set_document_purchase_token_cost(98-100)
packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (6)
packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs (21)
document_creation_token_cost(587-592)document_creation_token_cost(631-636)document_creation_token_cost(675-680)document_replacement_token_cost(594-599)document_replacement_token_cost(638-643)document_replacement_token_cost(682-687)document_deletion_token_cost(601-606)document_deletion_token_cost(645-650)document_deletion_token_cost(689-694)document_transfer_token_cost(608-613)document_transfer_token_cost(652-657)document_transfer_token_cost(696-701)document_purchase_token_cost(622-627)document_purchase_token_cost(666-671)document_purchase_token_cost(710-715)set_document_creation_token_cost(207-212)set_document_replacement_token_cost(214-219)set_document_deletion_token_cost(221-226)set_document_transfer_token_cost(228-233)set_document_price_update_token_cost(235-240)set_document_purchase_token_cost(242-247)packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (11)
document_creation_token_cost(10-10)document_replacement_token_cost(17-17)document_deletion_token_cost(24-24)document_transfer_token_cost(31-31)document_purchase_token_cost(45-45)set_document_creation_token_cost(54-54)set_document_replacement_token_cost(60-60)set_document_deletion_token_cost(66-66)set_document_transfer_token_cost(72-72)set_document_price_update_token_cost(78-78)set_document_purchase_token_cost(84-84)packages/rs-dpp/src/data_contract/document_type/token_costs/v0/mod.rs (12)
document_creation_token_cost(30-32)document_replacement_token_cost(34-36)document_deletion_token_cost(38-40)document_transfer_token_cost(42-44)document_price_update_token_cost(46-48)document_purchase_token_cost(50-52)set_document_creation_token_cost(57-59)set_document_replacement_token_cost(61-63)set_document_deletion_token_cost(65-67)set_document_transfer_token_cost(69-71)set_document_price_update_token_cost(73-75)set_document_purchase_token_cost(77-79)packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs (12)
document_creation_token_cost(20-24)document_replacement_token_cost(26-30)document_deletion_token_cost(32-36)document_transfer_token_cost(38-42)document_price_update_token_cost(44-48)document_purchase_token_cost(50-54)set_document_creation_token_cost(58-62)set_document_replacement_token_cost(64-68)set_document_deletion_token_cost(70-74)set_document_transfer_token_cost(76-80)set_document_price_update_token_cost(82-86)set_document_purchase_token_cost(88-92)packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs (5)
document_creation_token_cost(133-135)document_replacement_token_cost(137-139)document_deletion_token_cost(141-143)document_transfer_token_cost(145-147)document_purchase_token_cost(153-155)packages/rs-dpp/src/data_contract/document_type/v1/mod.rs (6)
set_document_creation_token_cost(78-80)set_document_replacement_token_cost(82-84)set_document_deletion_token_cost(86-88)set_document_transfer_token_cost(90-92)set_document_price_update_token_cost(94-96)set_document_purchase_token_cost(98-100)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (6)
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (1)
state_transition(9-22)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (4)
token_payment_info(6-11)token_payment_info_ref(13-18)set_token_payment_info(20-25)clear_token_payment_info(27-32)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/v0_methods.rs (14)
id(9-9)id(34-36)set_id(12-12)set_id(38-40)document_type_name(15-15)document_type_name(42-44)data_contract_id(24-24)data_contract_id(54-56)set_data_contract_id(28-28)set_data_contract_id(62-64)identity_contract_nonce(29-29)identity_contract_nonce(66-68)set_identity_contract_nonce(30-30)set_identity_contract_nonce(70-72)packages/rs-dpp/src/data_contract/document_type/accessors/v0/mod.rs (2)
data_contract_id(77-77)set_data_contract_id(95-95)packages/rs-dpp/src/data_contract/document_type/v0/accessors.rs (2)
data_contract_id(102-104)set_data_contract_id(125-127)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v0/v0_methods.rs (1)
set_identity_contract_nonce(345-349)
packages/rs-dpp/src/data_contract/document_type/token_costs/v0/mod.rs (5)
packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs (21)
document_creation_token_cost(587-592)document_creation_token_cost(631-636)document_creation_token_cost(675-680)document_replacement_token_cost(594-599)document_replacement_token_cost(638-643)document_replacement_token_cost(682-687)document_deletion_token_cost(601-606)document_deletion_token_cost(645-650)document_deletion_token_cost(689-694)document_transfer_token_cost(608-613)document_transfer_token_cost(652-657)document_transfer_token_cost(696-701)document_purchase_token_cost(622-627)document_purchase_token_cost(666-671)document_purchase_token_cost(710-715)set_document_creation_token_cost(207-212)set_document_replacement_token_cost(214-219)set_document_deletion_token_cost(221-226)set_document_transfer_token_cost(228-233)set_document_price_update_token_cost(235-240)set_document_purchase_token_cost(242-247)packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (11)
document_creation_token_cost(10-10)document_replacement_token_cost(17-17)document_deletion_token_cost(24-24)document_transfer_token_cost(31-31)document_purchase_token_cost(45-45)set_document_creation_token_cost(54-54)set_document_replacement_token_cost(60-60)set_document_deletion_token_cost(66-66)set_document_transfer_token_cost(72-72)set_document_price_update_token_cost(78-78)set_document_purchase_token_cost(84-84)packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (12)
document_creation_token_cost(6-6)document_replacement_token_cost(9-9)document_deletion_token_cost(12-12)document_transfer_token_cost(15-15)document_price_update_token_cost(18-18)document_purchase_token_cost(21-21)set_document_creation_token_cost(27-27)set_document_replacement_token_cost(30-30)set_document_deletion_token_cost(33-33)set_document_transfer_token_cost(36-36)set_document_price_update_token_cost(39-39)set_document_purchase_token_cost(42-42)packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs (12)
document_creation_token_cost(20-24)document_replacement_token_cost(26-30)document_deletion_token_cost(32-36)document_transfer_token_cost(38-42)document_price_update_token_cost(44-48)document_purchase_token_cost(50-54)set_document_creation_token_cost(58-62)set_document_replacement_token_cost(64-68)set_document_deletion_token_cost(70-74)set_document_transfer_token_cost(76-80)set_document_price_update_token_cost(82-86)set_document_purchase_token_cost(88-92)packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs (5)
document_creation_token_cost(133-135)document_replacement_token_cost(137-139)document_deletion_token_cost(141-143)document_transfer_token_cost(145-147)document_purchase_token_cost(153-155)
🪛 GitHub Check: Rust packages (dash-sdk) / Linting
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs
[failure] 575-575: failed to resolve: use of undeclared type BasicError
error[E0433]: failed to resolve: use of undeclared type BasicError
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:575:33
|
575 | ... BasicError::TokenPaymentByBurningOnlyAllowedOnInternalTokenError(
| ^^^^^^^^^^ use of undeclared type BasicError
|
help: consider importing this enum through its public re-export
|
9 + use crate::consensus::basic::BasicError;
|
[failure] 574-574: failed to resolve: use of undeclared type ConsensusError
error[E0433]: failed to resolve: use of undeclared type ConsensusError
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:574:29
|
574 | ... ConsensusError::BasicError(
| ^^^^^^^^^^^^^^ use of undeclared type ConsensusError
|
help: consider importing this enum through its public re-export
|
9 + use crate::consensus::ConsensusError;
|
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
🔇 Additional comments (411)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/transformer.rs (26)
5-8: Imports for consensus errors and result types look good.
No issues found. They accurately bring in the needed error and validation result types.
10-12: New imports for DocumentBaseTransition versions are appropriate.
No concerns; these imports match the usage of V0 and V1 transitions below.
14-17: Token modules and payment info imports are correctly referenced.
No issues; these additional tokens and payment info modules align with the new validation logic.
19-19: Error management import is correctly introduced.
No concerns; pulling in the crate-specificErrortype is consistent with the file’s usage.
25-29: Signature update with theaction: &strparameter is clear and flexible.
The addition ofactionfor detailed errors is well-structured.
30-31: Fetching the data contract by ID seems correct.
Error handling via?is also appropriate here.
34-34: Document type retrieval aligns with the data contract usage.
Looks good; it ensures we get the correctDocumentType.
35-35: Retrieving the document action token cost is consistent with the new payment logic.
No issues found.
36-36: Usingmapto transformdocument_action_token_costis a clean approach.
Helps avoid unnecessary branching.
37-43: Tuple extraction for token ID, effect, and token amount is correct.
However, double-check that theunwrap_or(data_contract_id)usage won't cause unintended behavior ifcontract_idis None.Please verify that omitting a customized
contract_idhere is always valid and intended.
45-50: Calculating the token ID withcalculate_token_idis straightforward.
No issues; the logic correctly uses the providedcontract_idbytes and position.
55-56: Conditional check forSome(document_action_token_cost)is correctly placed.
Ensures further validation only happens when a token cost is defined.
57-63: Error return for missing token payment info is correct.
It properly surfacesRequiredTokenPaymentInfoNotSetErrorif no payment info is present.
65-65: No functional changes aside from formatting/structure.
Skipping comment as there is no actionable code here.
67-67: Starting a new token contract compatibility check.
No direct issues to flag.
68-70: Callingmatches_token_contractto validate token contract constraints.
Logic ensures the user’s token contract references match what’s required.
71-82: Error handling for incorrect token usage is well-defined.
IdentityTryingToPayWithWrongTokenErrorconveys clear feedback.
83-83: No functional code within this line.
Skipping additional comment.
84-84: Whitespace or structural line.
Skipping additional comment.
85-85: Validating user’s agreed cost for the required token amount.
This lines up neatly before the numeric comparison.
86-87: Usingis_valid_for_required_costfor cost validation.
Appropriate method call to ensure user’s min & max cost offers overlap the required amount.
88-101: Error pathway for insufficient or mismatched token guarantees is correct.
IdentityHasNotAgreedToPayRequiredTokenAmountErrorgives a precise explanation.
102-102: No functional code on this line.
Skipping comment.
103-103: Establishing where gas fees are paid from is consistent with the new logic.
No issues; the final fallback isDocumentOwner.
104-107: Mappinggas_fees_paid_bywithunwrap_orensures a default.
This default approach works smoothly with optional token payment info.
114-116: BuildingDocumentBaseTransitionActionV0final struct is well-structured.
Matches the fields set above. No further issues.packages/rs-dpp/src/tokens/token_payment_info/methods/mod.rs (1)
1-1: Module declaration looks good.The module export declaration follows the Rust convention for organizing code with versioned modules.
packages/rs-dpp/src/document/extended_document/fields.rs (1)
5-5: Property name constant added correctly.The
TOKEN_PAYMENT_INFOconstant is appropriately defined with the$tokenPaymentInfovalue, following the same naming convention as other system properties in this module.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/fields.rs (1)
7-7: Property name constant added correctly.The
TOKEN_PAYMENT_INFOconstant is appropriately defined with the same$tokenPaymentInfovalue as in the extended document fields, ensuring consistency across the codebase.packages/rs-dpp/src/document/extended_document/accessors.rs (1)
7-7: Import added correctly.The
TokenPaymentInfotype is properly imported from the tokens module.packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_list/mod.rs (1)
132-132: Good practice: Unused parameter naming convention appliedThe parameter name change from
base_blockto_base_blockfollows Rust's convention for explicitly marking unused parameters, which helps suppress compiler warnings and makes the intention clear to other developers.packages/rs-dpp/src/document/extended_document/v0/serialize.rs (1)
128-128: Addition of token payment information fieldThe new
token_payment_info: Nonefield initializes the token payment information structure as part of the PR's objective to enhance payment processes for NFTs/documents. This ensures proper initialization during document deserialization.packages/rs-dpp/src/document/extended_document/serde_serialize.rs (1)
84-84: Consistent token payment field initializationThis change ensures the
token_payment_infofield is properly initialized toNoneduring deserialization via Serde, consistent with the change in the serialization module. The field supports the new token payment information feature described in the PR objectives.packages/rs-dpp/src/tokens/mod.rs (1)
10-15: Added new modules for token payment infrastructureThe addition of these three modules (
gas_fees_paid_by,token_amount_on_contract_token, andtoken_payment_info) is consistent with the PR objective of enhancing the payment process for NFTs/documents. These modules provide the foundation for implementing token payment information features.packages/rs-dpp/src/document/serialization_traits/platform_serialization_conversion/mod.rs (1)
113-115: Updated imports to support token payment featuresThe addition of
Documentto the imports fromcrate::documentandValuefromplatform_valueindicates preparation for handling token payment functionality in the test module. This ensures the necessary types are available for testing the new features.packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs (2)
2358-2358: Added token payment information parameterThe addition of the
Noneparameter indocuments_batch_create_transitioncorrectly updates the test to accommodate the new token payment information parameter, maintaining test compatibility with the enhanced document transition API.
2378-2378: Added token payment information parameterThe addition of the
Noneparameter indocuments_batch_update_transitioncorrectly updates the test to accommodate the new token payment information parameter, maintaining test compatibility with the enhanced document transition API.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/withdrawals/v0/mod.rs (3)
139-139: Added import for GasFeesPaidBy enumThe addition of this import is necessary to support the new gas fees payment mechanism, which aligns with the PR objective of specifying who pays the fees for state transitions requiring token payments.
173-173: Set default gas fees payment responsibilityThe addition of the
gas_fees_paid_byfield with the default value ofGasFeesPaidBy::DocumentOwnercorrectly implements the requirement that document owners should be responsible for gas fees in document transition tests. This is consistent with the PR's intent to define who pays for fees in state transitions.
317-317: Specified gas fees payment responsibility in withdrawal deletion testThe addition of the
gas_fees_paid_byfield withGasFeesPaidBy::DocumentOwnerensures that the test correctly reflects the expected behavior where document owners are responsible for paying gas fees when deleting withdrawal documents.packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (1)
1-42: Clean implementation with clear documentationThe
TokenPaymentInfoAccessorsV0trait is well-structured with comprehensive documentation for each method. It provides a complete set of accessors and mutators for token payment information, aligning with the PR objective of enhancing the payment process for NFTs/documents.The trait properly handles both reference and value semantics, offering methods that return cloned values where appropriate and references where optimization is needed. The inclusion of the
gas_fees_paid_byfield aligns with the PR description of adding a new field to determine who will pay the fees for state transitions.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/mod.rs (1)
10-10:✅ Verification successful
Updated test import to support token burning functionality
This change replaces the previous token contract creation function with one that specifically supports burning tokens. This aligns with the PR description indicating that payments made with internal tokens can be either transferred to the contract owner or burned.
🏁 Script executed:
#!/bin/bash # Check how the new function is used in test files echo "Searching for usage of the new function in test files..." rg "create_card_game_internal_token_contract_with_owner_identity_burn_tokens" --type rustLength of output: 3125
Final Update: Test Import Correctly Updated for Token Burning Functionality
The updated import now correctly references the new function, and its usage has been verified in multiple test files. This aligns with the PR description, ensuring that internal token payments can be transferred to the contract owner or burned as intended.
- The new function is used consistently across tests (e.g., in
transfer.rs,replacement.rs,deletion.rs,nft.rs, andcreation.rs).- No further changes are required based on the current test usage.
packages/rs-dpp/src/errors/protocol_error.rs (1)
287-292: Added new error variant for invalid transition actionsThe new
InvalidBatchedTransitionActionVarianterror provides specific feedback when an unexpected transition action variant is encountered. This enhances error handling for the token payment information feature, improving the validation process as mentioned in the PR objectives.The error message format follows the established pattern in the codebase, and the fields allow capturing both the expected and actual variant types for clear diagnostics.
packages/rs-dpp/src/data_contract/document_type/v0/accessors.rs (2)
2-2: Added import for DocumentTypeV0MutGetters traitAdded the
DocumentTypeV0MutGetterstrait to the import list to support schema mutation functionality.
21-25: Added implementation to support schema mutationThe implementation of
DocumentTypeV0MutGettersforDocumentTypeV0provides mutable access to the schema, which is an important addition for the token payment information feature. This allows the document schema to be modified to incorporate the new token payment fields.The implementation is concise and follows the established pattern of accessor implementations in this file.
packages/rs-dpp/src/state_transition/serialization.rs (1)
338-338: Addition of optional token payment info to document creation testThis change adds a
Nonevalue as the fourth element in the tuple, accommodating the new token payment information field in the document transition data structure. This aligns with the PR's objective to enhance payment processes for NFTs/documents.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/mod.rs (2)
9-9: Import of DocumentActionTokenEffect for enhanced token cost informationThe addition of this import supports the updated token cost method signature below, enabling more detailed token payment effects in document transitions.
81-85: Enhanced token cost method signature with token effect informationThe return type has been updated to include
DocumentActionTokenEffect, providing more detailed information about the token's effect in document transitions. This change directly supports the PR's goal of introducing structured token payment information with specific rules for external vs internal tokens.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/from_document.rs (1)
1-23: Implementation of document conversion with token payment supportThis new implementation adds support for constructing a
DocumentBaseTransitionV1from a document with optional token payment information. The method correctly extracts and maps all required fields, maintaining a well-scoped visibility for proper encapsulation. This is a key component for enabling the token payment feature described in the PR objectives.packages/rs-dpp/src/document/extended_document/mod.rs (2)
23-23: Added From derive macro for improved type conversionAdding the
Fromderive macro enables more ergonomic conversions between types, which is good practice when working with enum variants like this.
646-646: Added token payment info field to test document creationThis change adds support for the new optional token payment information field in the test document creation function, ensuring that the test infrastructure properly reflects the new data model with token payment capabilities.
packages/rs-dpp/src/tokens/token_amount_on_contract_token.rs (5)
1-9: Import organization is well structured.The imports are nicely organized by category (errors, data types, other modules) which makes the file easier to understand.
10-18: Well-documented token effect enum with appropriate default.The enum clearly defines two possible token effects: transferring to contract owner (default) or burning. The comment about external tokens not supporting burning is important context.
20-27: Clean implementation of enum-to-integer conversion.The
From<DocumentActionTokenEffect>foru8implementation correctly maps each enum variant to a specific integer value, following a common pattern in the codebase.
29-44: Robust error handling for invalid token effect values.The
TryFrom<u8>implementation properly handles invalid values by returning a specific error type that includes the allowed values and the received value, which will be helpful for debugging.
46-61: Consistent error handling pattern for u64 conversion.The implementation follows the same pattern as seen in the GasFeesPaidBy conversions, first attempting to convert u64 to u8 and then using the u8 implementation, which avoids code duplication.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/v0/from_document.rs (4)
7-7: Added import for TokenPaymentInfo.The TokenPaymentInfo import is correctly added to support the new parameter.
13-21: Added token_payment_info parameter to method signature.The method signature is updated to include the new optional TokenPaymentInfo parameter, matching the pattern used in other document transition methods.
22-30: TokenPaymentInfo correctly passed to base transition.The token_payment_info parameter is properly passed to the DocumentBaseTransition::from_document method call.
13-38:❓ Verification inconclusive
Consider adding test coverage for token payment functionality.
While the implementation is correct, ensure that test cases are added or updated to verify the token payment information is properly handled during document transfers.
🏁 Script executed:
#!/bin/bash # Check if there are tests for token payment info in document transfers echo "Searching for test cases involving TokenPaymentInfo in document transfers:" rg -A 3 -B 3 "token_payment_info.*DocumentTransferTransition" --type rustLength of output: 234
Action Required: Add or Verify Test Coverage for Token Payment Functionality
While the implementation in
from_documentis correct, our automated search did not surface any tests directly verifying that theTokenPaymentInfofield is properly handled during document transfers. Please manually verify if such test cases exist. If not, consider adding tests that cover scenarios whereTokenPaymentInfois both provided and absent.
- Confirm that tests in the repository (especially under the tests directory for document transitions) validate the handling of
TokenPaymentInfo.- If tests are missing, add cases to ensure that the document transfer logic accurately reflects token payment functionality.
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (5)
1-8: Imports are well organized.All necessary imports for error handling, serialization, and encoding are included.
9-23: Well-documented enum with appropriate derives.The GasFeesPaidBy enum is properly documented with clear comments explaining each variant's purpose. The #[default] attribute correctly marks DocumentOwner as the default option.
25-33: Clean implementation of enum-to-u8 conversion.The From implementation for u8 correctly maps each enum variant to its corresponding integer value.
35-51: Robust error handling for invalid gas fee payer values.The TryFrom implementation properly returns a specific error when an invalid value is encountered, which includes information about allowed values.
53-68: Consistent error handling pattern for u64 conversion.The implementation correctly handles the conversion from u64 to u8 first, with proper error propagation, before attempting to convert to the enum type.
packages/rs-dpp/src/tests/fixtures/get_document_transitions_fixture.rs (2)
11-12: Added import for TokenPaymentInfo.The TokenPaymentInfo import is correctly added to support the updated function signature.
13-24: Updated function signature to include TokenPaymentInfo.The function signature for get_batched_transitions_fixture has been updated to include Option as part of the document data tuple, aligning with the changes in the document transition system.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/from_document.rs (3)
7-7: Import looks appropriate and consistentThe new import for
TokenPaymentInfofits in well and aligns with the changes introducing token payment details. No issues here.
34-34: Seamless pass-through oftoken_payment_infoPassing
token_payment_infotoDocumentTransferTransitionV0::from_documentaligns with how similar transitions handle optional payment info. Good to maintain consistency across versions.
16-16:✅ Verification successful
Verify usage of the optional parameter in callers
This new
token_payment_info: Option<TokenPaymentInfo>parameter is coherent with the broader changes adding token payment metadata. However, ensure that all code paths invoking this method correctly provide an appropriate value (orNone) to avoid runtime mismatches.You can run the following search to confirm all callers are updated accordingly:
🏁 Script executed:
#!/bin/bash rg -A 3 "from_document\("Length of output: 79934
Action Required: Confirm Consistent Token Payment Parameter Propagation
The change adding the new
token_payment_info: Option<TokenPaymentInfo>parameter appears to be properly reflected in all relevant call sites within the RS-DPP code. In all direct callers of thefrom_documentfunctions for transfer, replacement, deletion, and base transitions, the updated parameter is correctly provided—either passing a concrete token payment object orNoneas appropriate. Additionally, while some RS-SDK wrappers (e.g. in transfer transitions) use alternative parameters (such asrecipient_idorrecipient_owner_id), these calls follow the intended conversion logic, ensuring the underlying RS-DPP methods receive the correct token payment information.
- RS-DPP Callers: Verified across v0 and v1 methods (e.g., in
document_transfer_transition,document_replace_transition,document_delete_transitionanddocument_base_transition), thetoken_payment_infoparameter is explicitly passed.- RS-SDK Wrappers: Although they pass parameters like
recipient_idorprofilerather than a direct token payment value, these wrappers are intended to convert or encapsulate the token payment metadata before calling the RS-DPP functions.No inconsistencies were found in the provided search output. Please confirm that any higher-level wrappers continue to correctly manage the conversion to the
token_payment_infooptional value.packages/rs-dpp/src/tokens/token_payment_info/mod.rs (1)
1-140:❓ Verification inconclusive
Solid approach to versioning—consider a fallback or stricter validation for
$format_versionThis new module establishes a strong foundation for token payment info with a clear enum-based version system. One potential gap is handling a missing or inconsistent
$format_version. Currently, if$format_versionis absent or invalid, the code implicitly errors out. This is acceptable, but adding a fallback or more verbose error context can improve debugging.If you want to ensure thorough usage, run:
to verify all call sites gracefully handle the
ProtocolError.
🏁 Script executed:
#!/bin/bash rg -A 3 "TokenPaymentInfo::try_from"Length of output: 36
Attention: Revisit
$format_versionHandling & Error Context in Version ConversionThe enum-based versioning strategy is solid. That said, the current implementation of
TryFrom<BTreeMap<String, Value>> for TokenPaymentInfo
simply errors out via aProtocolErrorwhen$format_versionis missing or invalid. While this behavior is acceptable, you might consider:
- Adding a fallback mechanism for when
$format_versionis absent.- Enhancing the error context in the returned
ProtocolError(e.g., including more detailed diagnostics) to aid debugging.Since the initial search (
rg -A 3 "TokenPaymentInfo::try_from") produced no output, please manually verify that all call sites correctly anticipate and gracefully handle these errors during conversion.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/mod.rs (3)
6-7: New modules introduced for V1 document transition support.These new modules are part of the token payment information feature, providing implementation for the V1 version of document base transitions that support token payments.
17-17: Added import for the new DocumentBaseTransitionV1 type.This import is required to reference the new V1 variant in the enum definition below.
46-47: Added V1 variant to DocumentBaseTransition enum.The new V1 variant encapsulates the DocumentBaseTransitionV1 type, which extends the transition functionality to include token payment information as mentioned in the PR objectives.
packages/rs-drive-abci/tests/supporting_files/contract/crypto-card-game/crypto-card-game-in-game-currency-burn-tokens.json (2)
1-178: Well-structured test contract for token burning functionality.This test contract defines a crypto card game with token burning capabilities, aligning with the PR objective of enabling token payments with different effects (burning or transferring to contract owner). The token cost structure includes the new "effect" field (value 1 indicating burning tokens) for all operations.
The contract correctly defines two tokens (gold and gas) with appropriate localization settings and sets up comprehensive card properties and indices for efficient querying.
13-22: Token cost configuration for document operations.The token cost structure properly implements the burning effect (effect: 1) for all operations, which aligns with the PR description of enabling burning for internal tokens. Each operation has a clearly defined token position, amount, and effect.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/from_document.rs (3)
7-7: Added import for TokenPaymentInfo.This import is required for the new token payment parameter added to the method signature.
16-16: Added optional token payment information parameter.This parameter enables the document creation process to include token payment details, which is a key part of the PR objective to enhance the payment process for NFTs/documents.
27-27: Forwarding token payment information to the base transition.The parameter is correctly passed to the DocumentBaseTransition::from_document method, ensuring that token payment information is available throughout the transition pipeline.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dpns/v0/mod.rs (2)
428-429: Updated test fixture to include token payment information parameter.The None value has been added to the fixture to accommodate the new token payment parameter in the document transition creation, ensuring test compatibility with the updated API.
448-451: Updated create transition action with improved result handling.The test now properly passes the owner_id to the action creation method and adds appropriate result handling to extract the document action. This ensures the test works correctly with the new token payment functionality.
packages/rs-dpp/schema/meta_schemas/document/v0/document-meta.json (2)
291-323: Good implementation of the documentActionTokenCost schema definition.The schema for document token costs is well-structured with clear types, constraints, and required fields. The
effectandgasFeesPaidByproperties have helpful descriptions explaining the possible values and their meanings.
489-512: LGTM - Comprehensive tokenCost schema with appropriate references.The tokenCost property effectively groups the token costs for various document actions (create, replace, delete, etc.) while maintaining consistency by referencing the documentActionTokenCost definition. Good practice to explicitly disallow additional properties.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/v0_methods.rs (2)
17-18: Good addition of document_type_name_owned method.Adding this method provides a way to get ownership of the document type name, which complements the existing reference-returning method. This pattern is consistent with Rust's ownership model.
46-48: Implementation matches the trait definition correctly.The implementation simply returns the document_type_name field, transferring ownership as expected.
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_replace_transition.rs (3)
13-14: Added necessary imports for new token functionality.These imports support the enhanced token functionality, particularly the new DocumentActionTokenEffect enum that's used to determine the operation type.
40-41: Good extraction of contract_owner_id for token transfers.Retrieving the contract owner ID is necessary for the new token transfer functionality when the effect is TransferTokenToContractOwner.
71-89: Robust implementation of token effect handling.The code now properly handles different token effects using a match statement that creates the appropriate operation type:
- TransferTokenToContractOwner: Transfers tokens from document owner to contract owner
- BurnToken: Burns tokens from the document owner's balance
This implementation aligns well with the schema changes and provides flexible token handling options.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs (3)
5-11: Good implementation of token_payment_info method.The method correctly handles version differences through pattern matching. For V0 it returns None (since V0 doesn't support token payments), and for V1 it returns the actual token payment info.
20-25: LGTM - set_token_payment_info implemented properly.The method correctly handles both variants, doing nothing for V0 (which doesn't support payment info) and delegating to the V1 implementation for V1.
27-32: LGTM - clear_token_payment_info implemented properly.The method correctly handles both variants, doing nothing for V0 (which doesn't support payment info) and delegating to the V1 implementation for V1.
packages/rs-dpp/src/tokens/token_payment_info/methods/v0/mod.rs (1)
7-42: Well-structured token payment validation traitThe
TokenPaymentInfoMethodsV0trait provides a clean and effective implementation of validation and token ID calculation methods for token payment information. The three methods handle necessary functionality:
- Validating cost requirements against min/max bounds
- Matching token contracts by ID and position
- Calculating token IDs with appropriate fallback
The structure ensures proper validation of token payments, which directly supports the PR's objective of enhancing the payment process for NFTs/documents.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/data_triggers/triggers/dashpay/v0/mod.rs (6)
157-162: Updated fixture initialization to include token payment info parameterThe fixture initialization now includes a fourth
Noneparameter in the transition tuples, which represents the new token payment information field that's being introduced in this PR.
187-191: Updated function call chain for document transition processingThe function call to
try_from_document_borrowed_create_transition_with_contract_lookupnow:
- Properly passes the owner ID as a parameter
- Adds an additional call to
into_data()before retrieving the document actionThis ensures the test correctly works with the new token payment information feature.
265-270: Consistent fixture update across all test casesThe same pattern of fixture initialization with the additional
Noneparameter is correctly applied to other test cases, ensuring consistent test setup.
310-313: Consistent function call updates across all test casesThe same updates to the
try_from_document_borrowed_create_transition_with_contract_lookupfunction call and subsequent processing are correctly applied to all test cases, maintaining consistency in the test implementation.
398-403: Final test case correctly updated with token payment parameterThe test case for identity existence validation correctly follows the same pattern of including the token payment information parameter.
428-431: Final test case function call correctly updatedThe function call chain in the final test case is properly updated to match the new signature and processing requirements.
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_delete_transition.rs (3)
8-10: Added essential imports for token handlingThe new imports
DataContractV0GettersandDocumentActionTokenEffectare necessary to support the enhanced token handling functionality.
36-37: Added contract fetch info retrievalFetching the contract information early is necessary to access the contract owner ID later during token transfers.
61-79: Improved token effect handling with flexible token operationsThe implementation now handles two distinct token effects:
TransferTokenToContractOwner: Creates a token transfer operation from the document owner to the contract ownerBurnToken: Creates a token burn operation (preserving the existing functionality)This directly implements the PR's requirement that "payments made with external tokens can only be transferred to the contract owner, while payments made with internal tokens can either be transferred to the contract owner or burned."
The structure using pattern matching is clean and easily extensible for future token effects.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/from_document.rs (3)
6-6: Added TokenPaymentInfo importThe import for
TokenPaymentInfois correctly added to support the new parameter in thefrom_documentmethod.
14-14: Added token payment info parameter to method signatureThe
token_payment_infoparameter is added to thefrom_documentmethod, allowing token payment information to be specified when creating document replace transitions.
31-31: Passed token payment info to underlying implementationThe token payment information is correctly forwarded to the version-specific implementation of
from_document.packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (2)
29-29: No issues with this new error import.
The usage ofTokenPaymentByBurningOnlyAllowedOnInternalTokenErroraligns well with the new validation logic.
54-57: Imports for token payment logic look correct.
The additions ofGasFeesPaidBy,DocumentActionTokenCost, andDocumentActionTokenEffectmatch the new fields in the schema and provide a clear, structured approach to token payment metadata.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/v0/from_document.rs (3)
7-7: Import is consistent with the new token payment parameter.
IncludingTokenPaymentInfohere ensures that the replacement transition can handle optional token payment data.
15-15: Newtoken_payment_infoparameter is properly introduced.
Forwarding an optional token payment descriptor aligns with the updated design for handling token-based actions.
24-24: Passingtoken_payment_infoto the base transition is correct.
This ensures all necessary token payment details remain available during the replacement transition workflow.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/v0/from_document.rs (3)
6-6: Import is consistent with enhanced token payment requirements.
Same rationale as with replacements: havingTokenPaymentInfoavailable aids in handling token-based logic during deletions.
14-14: Passingtoken_payment_infoparameter is aligned with the updated interface.
Ensures optional token payment data can be used or validated when deleting documents.
23-23: Properly includes token payment data in the base transition call.
Maintains consistency across create, replace, and delete transitions for token handling.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/from_document.rs (3)
6-6: Added import for TokenPaymentInfoThe import for TokenPaymentInfo is appropriately added to support the new token payment functionality introduced in this PR.
15-15: Token payment information parameter added consistentlyThe optional
token_payment_infoparameter has been correctly added to the method signature to support the new token payment feature. The parameter being optional (Option) ensures backward compatibility.
33-33: Parameter correctly forwarded to implementationThe token_payment_info parameter is properly passed to the DocumentCreateTransitionV0::from_document method, ensuring the implementation receives the payment information.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs (3)
9-9: Added TokenPaymentInfo importThe import for TokenPaymentInfo is appropriately added to support the new token payment functionality.
15-15: Token payment information parameter added consistentlyThe optional
token_payment_infoparameter has been correctly added to the method signature, consistent with the changes made to other transition types.
32-32: Parameter correctly forwarded to implementationThe token_payment_info parameter is properly passed to the DocumentDeleteTransitionV0::from_document method, ensuring the implementation receives the payment information.
packages/rs-dpp/src/errors/consensus/basic/basic_error.rs (2)
26-32: New errors for token payment validationsThe UnknownGasFeesPaidByError, UnknownDocumentActionTokenEffectError, and other token-related imports added here support the new token payment features described in the PR objectives.
508-517: New error types for token payment validationThese new error types are well-structured and appropriately follow the existing pattern in the file. Each error has the #[error(transparent)] attribute, consistent with other errors in the enum.
The new errors address specific validation cases for token payments:
- UnknownGasFeesPaidByError: For validating who pays gas fees
- UnknownDocumentActionTokenEffectError: For validating token effects
- TokenPaymentByBurningOnlyAllowedOnInternalTokenError: For validating burning operations
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/convertible.rs (1)
37-41: Reorganized imports with more specific feature flagsThe import for BTreeValueRemoveFromMapHelper has been moved to its own line with a more specific feature flag condition. This change doesn't affect functionality but makes the feature dependencies more explicit.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/from_document.rs (2)
10-10: Added new import for TokenPaymentInfoThe
TokenPaymentInfoimport has been added to support the new token payment functionality.
17-17: Support for token payment information added to document purchase transitionsThe method signature has been updated to include a new optional parameter
token_payment_infowhich is then passed to the underlying implementation. This change aligns with the PR objectives to enhance the payment process for NFTs/documents by allowing specification of token payment details.Also applies to: 35-35
packages/rs-dpp/src/errors/consensus/state/token/mod.rs (3)
2-2: New error type for token payment amount verificationAdded new error module
identity_has_not_agreed_to_pay_required_token_amount_errorand corresponding public export to handle cases where an identity hasn't agreed to pay the required token amount.Also applies to: 26-26
6-6: New error type for incorrect token selectionAdded new error module
identity_trying_to_pay_with_wrong_token_errorand corresponding public export to handle cases where an incorrect token is used for payment.Also applies to: 30-30
16-16: New error type for missing token payment informationAdded new error module
required_token_payment_info_not_set_errorand corresponding public export to handle cases where required token payment information is missing.Also applies to: 40-40
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_create_transition.rs (2)
15-16: Added imports for token effect handlingAdded imports for
DataContractV0GettersandDocumentActionTokenEffectto support the enhanced token payment logic.
70-88: Enhanced token effect handling in document creationThe code now supports two different token effects:
TransferTokenToContractOwner- Transfers tokens from the document owner to the contract ownerBurnToken- Burns tokens from the document owner's balanceThis implementation aligns with the PR objectives which specify different rules for external tokens (can only be transferred to contract owner) and internal tokens (can be transferred or burned).
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_base_transaction_action/state_v0/mod.rs (2)
4-4: Added imports for token account validationAdded imports for
IdentityTokenAccountFrozenErrorandIdentityTokenInfoV0Accessorsto support checking if token accounts are frozen.Also applies to: 6-6
43-71: Added validation for frozen token accountsEnhanced the validation logic to:
- Fetch identity token information with costs
- Check if the token account is frozen
- Return an appropriate error if the account is frozen
This additional validation improves the robustness of the system by ensuring that token accounts used for payments are not in a frozen state.
packages/rs-dpp/src/document/document_factory/mod.rs (2)
20-20: Ensure feature gating for token imports if necessary
The added import ofTokenPaymentInfoseems consistent with the newly introduced optional field in the tuple. IfTokenPaymentInfoshould only be used under certain build features or configurations, please ensure proper gating is in place. Otherwise, this import is good to go.
121-126:✅ Verification successful
Verify usage of the expanded tuple signature
The tuple in this signature now includesOption<TokenPaymentInfo>. Please confirm that all call sites within the codebase have been updated accordingly and properly handle the new optional token payment data.
🏁 Script executed:
#!/bin/bash # Searches for create_state_transition invocations to ensure the new 4-element tuple usage is consistent. rg -A 3 "create_state_transition"Length of output: 58271
Confirmation of expanded tuple handling across call sites
After searching forcreate_state_transitionreferences throughout the codebase, all detected calls appear to use the updated 4-element tuple—including the newOption<TokenPaymentInfo>field. There are no obvious call sites still using an outdated signature, and the tests as well as the various factory methods in both the standard and specialized document factories (as well as their wasm counterparts) have been updated accordingly.
- Verified usage in packages/rs-dpp/src/document/document_factory/mod.rs and related specialized factories.
- Call sites in both production code (e.g., document facade) and tests now pass/handle the 4-element tuple.
No further action is required here.
packages/rs-dpp/src/document/specialized_document_factory/mod.rs (2)
20-20: Check that token payment info is only used when needed
The new import ofTokenPaymentInfoaligns with the added logic in the extended tuple. Ensure internal modules or tests do not unintentionally depend on this unless required.
124-129:✅ Verification successful
Confirm tuple change impacts
By addingOption<TokenPaymentInfo>to the tuple, you are broadening the data passed to state transitions. Verify that any downstream consumers can handle aNoneor valid token info without unexpected errors.
🏁 Script executed:
#!/bin/bash # Check references of create_state_transition to ensure no mismatch in tuple arity or usage rg "create_state_transition" -A 5Length of output: 69106
Confirmed tuple change compatibility
After reviewing the grep results for
create_state_transition, there’s no evidence of any tuple arity mismatch or misuse in downstream consumers. All the call sites appear to work with the modified tuple structure that now includes anOption<TokenPaymentInfo>. That said, please ensure that runtime tests or integration tests verify that bothNoneand valid token info values are handled gracefully in the state transition logic.packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_document_action_token_effect_error.rs (3)
1-7: Validate file placement and naming
Adding a dedicated error type for unknown token effects is a good practice. The file path and naming scheme seem consistent with existing patterns for specialized error definitions. Ensure this placement remains intuitive and well-documented in your error-handling guidelines.
8-20: Review struct design for clarity and possible expansions
This struct includes bothallowed_values(as bytes) and areceivedvalue. If the allowed values might eventually need to be more verbose or typed, consider more descriptive or strongly typed fields. For now, the design is sensible.
39-43: Error conversion fits existing patterns
Wrapping the new error withinBasicErrormaintains consistency with the overallConsensusErrorflow. This looks good and keeps handling uniform across the codebase.packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_purchase_transition.rs (3)
12-13: Imports for contract accessors and token effects
The newly added imports (DataContractV0GettersandDocumentActionTokenEffect) align with the enhanced token logic. No issues acknowledged; these are appropriate for referencing token effects in subsequent logic.
42-43: Expose contract owner ID usage
Introducinglet contract_owner_id = contract_fetch_info.contract.owner_id();clarifies ownership relationships for subsequent operations. Ensure that any fallback or error handling is in place if the contract has no valid owner in edge cases.
84-101: Token effect handling is clearly segmented
The match statement forDocumentActionTokenEffectis well-structured, allowing separate logic for transferring tokens to the contract owner versus burning. This improves maintainability and clarity of future expansions.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/v0/from_document.rs (3)
8-8: Clean import for optional payment information
The addition of this import correctly introducesTokenPaymentInfofor broader token payment handling.
17-17: Optional token payment parameter
Providingtoken_payment_infoas anOptionis a flexible approach, allowing transitions to proceed even without token payment details. This aligns with the PR objectives for an optional fee-payer scenario.
34-34: Passing token payment info to the base transition
Forwardingtoken_payment_infoensures the base transition can fully integrate payment data if present.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs (4)
5-5: Introducing DocumentBaseTransitionV1
ImportingDocumentBaseTransitionV1lays the foundation for version-specific logic, preserving backward compatibility.
7-7: Importing TokenPaymentInfo
This import is necessary for the new parameter in the transition function.
15-15: Appending token_payment_info parameter
Includingtoken_payment_infoin the signature aligns with the new versioned transition approach and ensures the optional payment data is captured.
33-39: Version-specific dispatch to DocumentBaseTransitionV1
This match branch introduces support for feature version 1 by invokingfrom_documentonDocumentBaseTransitionV1, providing a clear upgrade path from V0.packages/rs-dpp/src/errors/consensus/state/token/required_token_payment_info_not_set_error.rs (1)
1-42: New error type for missing token payment info
DefiningRequiredTokenPaymentInfoNotSetErrorimproves error clarity by explicitly stating which token and action lack payment information. The conversion intoConsensusErroris cleanly handled, integrating well with existing error flows.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0_methods.rs (10)
12-12: Support for retrieving ID from V1 variant
Allowing retrieval of the ID from bothV0andV1ensures consistent usage.
19-19: Support for setting ID in V1
Mirroring the approach in V0, now extended to V1.
26-27: Consistent retrieval of document type name
The new branch (V1) matches V0 logic, preserving a unified interface.
29-32: New owned document type name method
Exposing an owned name from both V0 and V1 is beneficial for scenarios where a String is required.
39-39: Set document type name for V1
Ensures parity with V0 method signature and functionality.
46-47: Data contract ID retrieval from V1
Extends data contract ID access to the new variant.
53-54: Reference to V1 data contract ID
Providing a borrowed reference maintains consistency with the existing pattern.
59-60: Setting data contract ID in V1
Again, parallels the V0 approach, ensuring uniform updates.
67-68: Access to identity contract nonce in V1
Allows the new variant to store nonce similarly to V0.
74-75: Setting identity contract nonce in V1
Ensures the nonce can be updated in both versions.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/mod.rs (3)
27-27: No issues with conditional compilation directive
This#[cfg(feature = "state-transition-value-conversion")]line is straightforward and does not raise any concerns. It conditionally includes logic only when the feature is enabled, which helps keep the binary lightweight otherwise.
39-39: New import reference
The import ofDocumentBaseTransitionV0Methodsappears correct and aligns with the usage within this file.
295-376: Confirm version mismatch error logic
The fallback for unrecognizeddocument_structure_version(lines 371-374) appropriately returns anUnknownVersionMismatcherror. Ensure that all external calls, tests, or usage sites either handle or do not produce unexpected version numbers. Logging more context (like the provided version) might also aid future debugging.Would you like me to generate a script to scan the codebase for references to this method that might use an unrecognized version?
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/transfer.rs (1)
72-72: Check optional token payment parameter usage
Multiple invocations ofBatchTransition::new_document_*_transition_from_document(...)now include aNonefor the token payment–related argument(s). If the design intentionally defers token payment information, this is fine. However, confirm there are no side effects where a required token payment is omitted inadvertently. Ensure that tests cover scenarios with and without token payment.Also applies to: 119-119, 228-228, 320-320, 454-454, 528-528, 548-548, 700-700, 807-807, 900-900, 970-970, 1048-1048, 1101-1101, 1195-1195
packages/rs-dpp/src/errors/consensus/state/state_error.rs (1)
281-292: New token-related error variants
The added errors –IdentityHasNotAgreedToPayRequiredTokenAmountError,RequiredTokenPaymentInfoNotSetError, andIdentityTryingToPayWithWrongTokenError– extend error coverage for token-based operations. Ensure these are well-documented, tested, and leveraged correctly throughout the codebase to avoid silent failures.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/mod.rs (1)
1-94: Added DocumentBaseTransitionV1 struct implementation
- Structured approach: The introduction of
DocumentBaseTransitionV1with atoken_payment_infofield brings a clear, versioned extension to base document transitions.- from_value_map_consume: This method correctly handles optional fields like
token_payment_infoby attempting to parse a map. Recommend adding thorough unit tests to cover malformed or missing fields.- Serialization: The
Encode,Decode, and optionalserdeattributes are well-applied. Verify usage with any third-party tooling to ensure no compatibility regressions.Overall, the code structure looks good and should enhance flexibility for token payment data.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/v0/from_document.rs (2)
10-10: Added import for TokenPaymentInfoThe new import aligns with the added parameter in the function signature.
17-17: Added token_payment_info parameter to function signature and implementationThe function now accepts an optional TokenPaymentInfo parameter and correctly passes it to the DocumentBaseTransition::from_document method. This change supports the PR objective of allowing users to specify token payment information during document price updates.
Also applies to: 26-26
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/deletion.rs (4)
5-5: Updated import for token contract creationChanged from using
create_card_game_token_contract_with_owner_identitytocreate_card_game_internal_token_contract_with_owner_identity_burn_tokens, which reflects the new functionality for handling internal tokens with burn capability.
61-61: Added None parameter for token_payment_info in test function callsUpdated all function calls to
BatchTransition::new_document_creation_transition_from_documentandBatchTransition::new_document_deletion_transition_from_documentwithNoneparameter for token_payment_info. This maintains the original behavior in the tests while adapting to the new function signatures.Also applies to: 105-105, 244-244, 288-288, 410-410, 454-454, 576-576, 620-620, 713-713, 812-812, 872-872, 981-981, 1041-1041
773-774: Updated token contract creation function for testsNow using
create_card_game_internal_token_contract_with_owner_identity_burn_tokensinstead of the previous function. This change supports the PR objective of handling internal tokens differently, with the ability to burn tokens rather than just transfer them.
943-944: Updated token contract creation function in another testConsistently using the new
create_card_game_internal_token_contract_with_owner_identity_burn_tokensfunction across all tests, which ensures uniform token behavior testing.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/advanced_structure/v0/mod.rs (2)
12-12: Updated TokenContractPosition importNow importing TokenContractPosition directly from the data_contract module, which supports the type-safe refactoring in the token validation loop.
101-102: Updated error creation with proper type castingConsistent with the loop refactoring, the error creation now casts the expected position to
TokenContractPositionfor type consistency.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/from_document.rs (3)
9-9: Added import for TokenPaymentInfoThe import supports the new parameter added to the function signature.
16-16: Added token_payment_info parameter to function signatureThis change aligns with the PR objective of introducing token payment information to document transitions.
34-34: Passing token_payment_info to underlying implementationThe token_payment_info parameter is correctly forwarded to the DocumentUpdatePriceTransitionV0::from_document method.
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_update_price_transition.rs (3)
12-13: Imports look consistent with the new token-handling functionality.
40-40: Confirm contract ownership reference.Please ensure all contracts stored in
fetch_infoconsistently have anowner_id(). If not, consider adding a guard or fallback for missing owners.
66-83: Token cost application appears logically sound.The match statement correctly handles both burn and transfer scenarios. You may also consider validating
cost > 0in case a zero-cost edge case requires special handling.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/nft.rs (25)
50-50: AddedNoneparameter matches the updated signature.
66-66: Parameters updated to align with new API.
121-121: NewNoneargument follows the expanded function signature.
305-305:Noneusage is consistent with token cost refactoring.
433-433: PassingNoneensures no token effect for this test.
670-670: AdditionalNonereflects no token cost in this test scenario.
831-831: Maintaining consistency with newly introduced optional parameter.
1180-1180: Optional token parameter set toNonefor clarity.
1340-1340:Noneindicates no special token action.
1728-1728: Ensuring test covers default token effect scenario (i.e., none).
1775-1775: Signature updated withNoneas expected.
1826-1826: No token parameter is intentionally passed here.
1923-1923: Aligning arguments with revised constructor signature.
2021-2021: No token effect is tested by providingNone.
2103-2103: No concerns: matches updated function signature.
2170-2170: Parameter set toNoneto skip token operation testing.
2221-2221: Refactored method calls now require thisNoneparameter.
2282-2282: Consistency with transition API by passingNone.
2333-2333: ExtraNonealigns with expanded transition signature.
2389-2389: Leaving the token parameter asNoneis valid for this test.
2429-2429: Optional token cost not utilized here, soNoneis appropriate.
2618-2618: No token operation tested, so passingNone.
2760-2760: Explicitly supplyingNonefor any token effect parameter.
2906-2906: Maintaining uniformity with changes across similar calls.
3095-3095: Same approach toNonefor new token effect argument.packages/rs-dpp/src/errors/consensus/basic/data_contract/mod.rs (6)
37-37: New module for internal token-only burning errors.
40-40: Additional module to handle unknown token effect errors.
42-42: Introducing error handling for an unknown gas fees payer.
87-87: Exporting the newly added internal-burn-only error.
88-88: Exposing the unknown token effect error publicly.
90-90: Publicly re-exporting the unknown gas fees payer error.packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_gas_fees_paid_by_error.rs (2)
1-7: Imports look consistent.No issues found in these crate imports. They appear properly aligned with the error implementation.
8-23: Struct definition and derivations look good.The derived traits and error message provide clear context. The
allowed_valuesandreceivedfields align well with the error use case.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/replacement.rs (1)
64-64: Confirm correctness of passingNone.All these lines add an extra
Noneargument toBatchTransitionfactory methods. Verify that this new parameter is intentionallyNoneacross different test scenarios, or if a specific value is needed in some tests. Consider adding coverage to ensure the new parameter usage is tested thoroughly.Also applies to: 108-108, 218-218, 275-275, 566-566, 610-610, 794-794, 902-902, 1006-1006, 1071-1071, 1091-1091, 1225-1225, 1294-1294, 1314-1314, 1485-1485, 1554-1554, 1574-1574, 1749-1749, 1818-1818, 1838-1838, 2021-2021, 2068-2068
packages/rs-drive/src/state_transition_action/action_convert_to_operations/batch/document/document_transfer_transition.rs (3)
13-14: New imports for contract getters and token effects.These imports correctly match the usage below in handling
DocumentActionTokenEffectand retrieving contract owner information.
40-40: Capturing the contract owner ID.Storing
contract_owner_idfrom the fetched contract is necessary for transfers. This addition supports clearer logic downstream.
73-91: Token operation logic is clearly handled.The
if let Some(...)block properly matches token effects to either transfer or burn tokens. Ensure edge cases (e.g., zero cost) are covered by tests.packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (4)
1-2: Module declaration is straightforward.The
v0_accessorsmodule reference is properly exposed for usage.
3-49: Struct definition is comprehensive.All fields and derived traits (e.g.,
Display,Encode,Decode) appear consistent with the intended token payment info model. Good versioning approach.
51-97: Accessor trait implementation looks correct.Getters and setters for each field correctly delegate data access and mutability. No immediate issues observed.
99-125: Default fallback for unknowngasFeesPaidBymight obscure errors.The
matchon lines 116–120 defaults toGasFeesPaidBy::default()instead of returning an error if the string is unrecognized. This could mask invalid input. Verify whether silently defaulting is intentional or if an error is preferable.packages/rs-dpp/src/errors/consensus/codes.rs (2)
106-108: New error codes for token payment features look good.These errors align with the PR objectives of introducing token payment information, enabling validation of gas fee payment responsibility and token burning restrictions for external tokens. The codes follow the established numbering pattern for
BasicErrorvariants.
251-253: Comprehensive state error codes for token payment validation.These new state errors properly handle identity-specific token payment validation scenarios, following the established numbering pattern for
StateErrorvariants. They'll be useful for enforcing proper payment amounts and token types during document state transitions.packages/rs-drive-abci/src/execution/platform_events/block_processing_end_events/tests.rs (3)
82-82: Added token payment info parameter.The
Noneparameter corresponds to the new token payment information feature, aligning with other changes in this PR. This maintains compatibility with existing tests while supporting the new token payment functionality.
190-190: Consistent addition of token payment parameter.Another instance of the token payment information parameter being added to support the new feature while maintaining test functionality. All test cases remain consistent in their approach.
311-311: Consistently updated document deletion calls.All document deletion transition calls have been updated with the token payment info parameter set to
None, ensuring all test cases properly accommodate the new feature without changing test behavior.Also applies to: 411-411, 514-514, 613-613, 712-712, 812-812
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs (3)
3-9: Updated imports for token payment handling.These new imports support the token payment functionality by bringing in necessary types for fee results, validation results, and user fee handling. This aligns with the PR's objective of enhancing the payment process for document operations.
16-24: Enhanced method signature with token payment parameters.The method now accepts owner identity and fee increase parameters, and returns both validation results and fee information. This properly integrates token payment handling into the document deletion process.
27-27: Updated method call with new parameters.The implementation correctly passes the new parameters to the underlying version-specific method, maintaining the version abstraction pattern while supporting the new token payment functionality.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v0/mod.rs (4)
49-49: Field renamed to camelCase for consistency.The rename attribute has been updated from kebab-case (
$identity-contract-nonce) to camelCase ($identityContractNonce), aligning with JavaScript/JSON conventions and other fields in the codebase.
71-73: Simplified error handling for improved readability.The code has been refactored to use the
?operator directly instead of explicit error mapping, making the code more concise without changing its behavior.
75-75: Consistent error handling simplification.Similar to previous changes, this line uses the
?operator directly for error propagation, improving code readability.
91-91: Removed unnecessary namespace prefixes.The
std::marker::prefix has been removed from theSizedtrait bounds, making the code more concise without changing its functionality.Also applies to: 99-99, 106-106
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (15)
77-77: AddTokenAmountimport
No issues noted; this import facilitates handling token-based amounts.
83-84: Add new DataContract imports
These imports are consistent with upcoming functionality for managing contract positions and document type setters.
131-133: Add token-related imports
UsingGasFeesPaidBy,DocumentActionTokenCost, andDocumentActionTokenEffectappears aligned with the expanded token payment features.
1100-1100: PassingNonein transition creation
Verify that providingNoneat this position is compatible with the updated function signature and doesn't omit required token info.
1122-1122: Optional parameter check
Ensure that setting this parameter toNoneis intentional and the function call is valid when no additional data is passed.
1144-1144: ValidateNoneusage
Confirm this omission doesn't skip any required token or ownership details for document creation.
1165-1165: Confirm theNoneargument
Please ensure downstream logic handles the absence of supplemental data without errors.
1417-1417: Revisit parameter usage
Double-check that omitting this argument asNoneis fully supported by the updated batch transition API.
1439-1439: Optional param
Confirm thatNonehere doesn’t degrade the correctness of the document creation transition.
1461-1461: Potentially missing argument
Assess whether an explicit token payment information object was needed. If not, this is fine.
1482-1482: Confirm parameter optionality
Please verify that this parameter was indeed intended to beNonein all scenarios.
1643-1643: CheckNonefor consistency
Make sure the function logic accommodates the absence of extra transition data here.
1665-1665: Validate no additional data
Ensure there's no need for token or fee data in this particular creation call.
2375-2401: New method:create_card_game_internal_token_contract_with_owner_identity_burn_tokens
This approach to generating two distinct token IDs from one contract looks correct. Confirm that these IDs won't collide with any existing tokens.
2429-2471: New method:create_card_game_external_token_contract_with_owner_identity
Configures a “card” document type to transfer tokens to the contract owner. Verify that “card” exists in the JSON schema and that passing the cost parameters matches the contract’s final usage.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (6)
6-6: ImportingConsensusValidationResult&UserFeeIncrease
Indicates more advanced validation output and a mechanism for fee handling. Looks good.
13-13: AddBatchedTransitionActionimport
This is aligned with returning a consolidated transition action object within validation.
20-20: Newowner_idparameter
Make sure all callers supply a valid identity for ownership context in create transitions.
24-24: Newuser_fee_increaseparameter
Check that any logic applying user fee increments is thoroughly tested to prevent incorrect fees.
27-33: Refined return type
ReturningConsensusValidationResult<BatchedTransitionAction>plusFeeResultprovides a structured approach to validation feedback.
36-36: Updated function invocation
The call now passes ownership and fee parameters, consistent with the revised transition creation process.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/transformer.rs (4)
4-4: AddConsensusValidationResultimport
Important for conveying detailed validation outcomes from base transitions.
7-7: AddDocumentActionTokenCostimport
Enables retrieval and processing of token-related costs in base transition actions.
9-9: Add localErrorimport
Centralizing error handling helps unify the returned error structure from transformations.
19-27: Refactor to return a consensus-based validation result
Switching toConsensusValidationResult<Self>fosters clarity on whether the base transition is valid or needs further action.packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs (3)
22-39: Constructor implementation is clean and concise.Good use of
#[allow(clippy::too_many_arguments)]since all parameters are necessary for this error type. The constructor properly maps all input parameters to the corresponding struct fields.
66-91: Error message formatting is clear and comprehensive.The
Displayimplementation provides a clear, informative error message including all relevant token information. The formatting logic for handling both present and missing contract IDs is well-handled.
93-99: Good implementation of error traits and conversion.The implementation of the standard error trait and conversion to
ConsensusErroris correct, which ensures proper integration with the existing error handling system.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (11)
35-46: Good addition of token-related imports.The new imports correctly bring in the necessary types for token payment functionality, including
TokenConfiguration,GasFeesPaidBy,DocumentActionTokenCost, and token payment info types.
96-96: Added optional token payment information parameter.The
Noneparameter has been added to all document creation transitions to accommodate the newtoken_payment_infoparameter, maintaining backward compatibility while enabling the new token payment feature.Also applies to: 183-183, 246-246, 355-355, 536-536, 558-558, 580-580, 601-601, 960-960, 1234-1234, 1253-1253, 1582-1582, 1604-1604, 1626-1626, 1648-1648, 1669-1669, 1690-1690
2472-2612: Well-implemented token burn test.The test thoroughly validates burning tokens during document creation:
- Sets up a contract with token burning capability
- Adds tokens to buyer's identity
- Creates a document with token payment info
- Verifies the buyer's balance is reduced by the token cost
- Confirms that tokens were burned (contract owner's balance remains unchanged)
The test demonstrates the proper token burning mechanism, ensuring that the amount is deducted from the buyer's balance without being transferred to anyone else.
2615-2754: Complete token transfer test implementation.This test comprehensively validates token transfers during document creation:
- Creates a contract with token transfer capability
- Adds tokens to the buyer
- Creates a document with appropriate payment info
- Verifies the buyer's balance is reduced
- Confirms the contract owner received the tokens
The test effectively demonstrates that tokens can be transferred from the document creator to the contract owner during document creation.
2757-2888: Good test for insufficient payment agreement.This test validates that document creation fails when the user doesn't agree to pay enough tokens. It properly:
- Sets up a contract requiring 10 tokens
- Creates a document while only agreeing to pay 9 tokens
- Verifies the operation fails with the correct error
- Confirms the buyer's balance remains unchanged
This ensures proper validation of payment agreements before any tokens are transferred.
2891-3022: Important test for minimum cost setting.This test covers the edge case where a buyer sets a minimum cost higher than the required amount, which should fail. The test correctly:
- Creates a document while setting minimum_token_cost (12) higher than required (10)
- Verifies the transaction fails with the expected error
- Confirms the buyer's balance remains unchanged
This test is valuable for ensuring the system correctly handles unusual payment parameters.
3025-3151: Good test for excess payment agreement.This test verifies that when a user agrees to pay more than required, only the exact amount needed is transferred:
- User agrees to pay up to 12 tokens
- Contract only requires 10 tokens
- Confirms exactly 10 tokens are deducted (not 12)
This is an important validation to ensure users are not overcharged.
3154-3277: Proper validation of missing payment information.This test confirms that document creation fails when token payment info is not provided but required:
- Sets up a contract requiring token payment
- Attempts to create a document without providing payment info
- Verifies the operation fails with the correct error
This test ensures proper validation of the token payment requirement.
3280-3412: Comprehensive test for insufficient token balance.This test ensures that document creation fails when a user doesn't have enough tokens:
- Gives the user 8 tokens when 10 are required
- Attempts to create a document
- Verifies the correct error is returned
- Confirms the user's balance is unchanged
The test correctly validates token balance checking before document creation.
3415-3593: Thorough test for external token payments.This comprehensive test validates payments with tokens from external contracts:
- Creates separate contracts for tokens and documents
- Sets up token payments from an external contract
- Creates a document using the external token
- Verifies token balances are correctly updated
- Confirms tokens are transferred to the document contract owner
This test is critical for validating cross-contract token interactions.
2540-2546: Good token payment configuration with explicit gas fee assignment.The token payment configuration correctly specifies:
- No specific payment token contract (using the default)
- Position 0 for the token in the contract
- Maximum token cost limit (10)
- Gas fees explicitly paid by the document owner
This configuration provides a clear template for how token payments should be structured.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs (7)
241-241: Verify the source ofuser_fee_increase
Ensure this parameter is correctly propagated from all upstream calls. A quick verification can confirm no accidental mismatches.
635-642: Confirm test coverage for the fee increase logic
This block adds theuser_fee_increaseparameter to creation actions. Please ensure that there is a unit or integration test verifying the resulting fee calculations or behaviors.
714-718: Consistent approach to passinguser_fee_increase
These lines seamlessly integrate the new parameter into replace transitions, and the logic looks good.
729-733: Implementation looks consistent
The additional fee result operation aligns well with existing patterns here.
788-803: Transfer transition logic
This extension of the code to includeuser_fee_increaseis consistent with similar blocks and appears correct.
847-862: No issues found inDocumentUpdatePriceTransition
Integratinguser_fee_increasehere follows the existing pattern. Looks solid.
916-932: Document purchase transition
The usage ofuser_fee_increaseis coherent and consistent with the other transitions.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs (3)
48-54: Base action validation looks good
No issues found here—logic is straightforward and consistent.
56-76: Verify correctness of usinguser_fee_increaseduring error fallback
This portion creates aBumpIdentityDataContractNonceActionif the base validation fails. Confirm whether, in this error scenario, the fee increase should remain or reset.
142-153: Returning a well-structuredBatchedTransitionAction
This final assembly of the create action is neatly done, and the additional fields appear correctly set.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs (8)
146-146: New import usage
This import looks fine, assuming it's required for token contract setup.
155-155: Import for data contract getters
No concerns here—as long as it’s used, this addition is good.
161-162: Imports for document type accessors
Looks appropriate for the tests.
167-168: Additions ofTokenConfigurationandIdentityGettersV0
No issues; helpful for new token logic.
171-171: Usage ofplatform_value::Value
No concerns noted.
179-180: ImportingDocumentActionTokenCostandDocumentActionTokenEffect
Relevant for new token-based transitions. This is fine.
910-1032: External token transfer scenario
The logic and checks appear sound. Great job.
1539-1664: Burning external token disallowed test
The test is consistent with the intended restriction, nicely validating the consensus error.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_base_transition_action/v0/mod.rs (4)
4-11: New imports support enhanced token payment features.The added imports for
GasFeesPaidByandDocumentActionTokenEffectintroduce the necessary types to support the token payment information feature described in the PR objectives.
26-27: Enhanced token_cost field to include token effect.The
token_costfield has been updated to include aDocumentActionTokenEffectparameter, which aligns with the PR objectives of specifying how token payments should be handled (transferred or burned).
27-29: Added gas_fees_paid_by field to specify fee payer.This field addition implements the PR objective of determining who will pay the fees associated with state transitions that require token payments.
57-58: Updated accessor to match the new token_cost structure.The accessor method has been correctly updated to reflect the new tuple structure that includes the token effect.
packages/rs-dpp/src/data_contract/document_type/v1/mod.rs (2)
9-10: Updated imports to support token cost setters.The added imports provide the necessary types for the new token cost setter functionality. The implementation depends on
DocumentTypeV1SettersandTokenCostSettersV0to manage token costs for various document operations.Also applies to: 14-15, 17-19, 22-23
77-100: Added DocumentTypeV1Setters implementation for token costs.The implementation of
DocumentTypeV1SettersforDocumentTypeV1adds comprehensive support for setting token costs for various document actions (creation, replacement, deletion, transfer, price update, purchase). This aligns perfectly with the PR objective of enhancing the payment process for NFTs/documents.Each method correctly delegates to the underlying
token_costsfield, promoting clean code organization and separation of concerns.packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs (4)
12-20: New error type for token burning restrictions.This error type implements the PR objective rule that payments made with external tokens can only be transferred to the contract owner (not burned). The struct captures all necessary information to identify the problematic token and action.
22-54: Comprehensive accessor methods for error details.The implementation provides well-structured accessor methods that return information about the external token that cannot be burned. The
external_token_idmethod helpfully calculates the token ID from the contract ID and position.
56-70: Clear error message formatting.The custom Display implementation produces a detailed, user-friendly error message that includes all relevant information: token ID, contract ID, position, and action. This will help developers quickly understand and fix the issue.
72-76: Proper integration with consensus error handling.The implementation of
From<TokenPaymentByBurningOnlyAllowedOnInternalTokenError> for ConsensusErrorensures that this error can be properly propagated within the consensus error handling system.packages/rs-dpp/src/errors/consensus/state/token/identity_has_not_agreed_to_pay_required_token_amount_error.rs (5)
10-21: Well-structured error type with clear formatting.This error type supports the PR objective of allowing users to specify their own price range. The error formatting provides a clear message that includes all relevant information about the required amount and the user's offered range.
22-28: Comprehensive error fields for detailed diagnostics.The struct includes all necessary fields to understand the mismatch between required and offered token amounts, including token ID, required amount, min/max offers, and the action being performed.
30-46: Simple constructor with appropriate parameters.The constructor allows for easy creation of the error with all required details. The
#[allow(clippy::too_many_arguments)]annotation is appropriate given the number of fields needed to provide complete error information.
48-67: Comprehensive accessor methods.The implementation provides accessor methods for all fields, allowing other code to extract specific details about the error when needed.
69-73: Proper integration with consensus error system.The implementation of
From<IdentityHasNotAgreedToPayRequiredTokenAmountError> for ConsensusErrorensures that this error can be properly propagated as a state error within the consensus system.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/v0/transformer.rs (8)
4-5: Imports look good.No obvious issues with these added import lines.
9-10: New imports forErrorandBatchedTransitionAction.These are straightforward additions and appear to be correctly referenced elsewhere.
13-14: Adding DocumentTransitionAction and BumpIdentityDataContractNonceAction imports.No concerns—these additions are consistent with usage below.
20-21: New function parametersowner_idanduser_fee_increase.These parameters are introduced to handle user fee increments and the owner identifier in the transition. Be sure to confirm all potential call sites provide valid values.
23-29: Function return type expanded to includeFeeResult.Returning
(ConsensusValidationResult<BatchedTransitionAction>, FeeResult)is logical if you need to deliver both consensus validation outcomes and fee data. Confirm that returningFeeResult::default()by default is appropriate for delete operations.
32-38: Usingdocument_creation_token_cost()for a delete action.The code calls
document_type.document_creation_token_cost()inside a “delete” context. Check if there is a matching delete-specific cost function, or confirm that the creation token cost is indeed the intended value.
40-60: Base validation failure branch creates aBumpIdentityDataContractNonceAction.This fallback logic looks consistent. Verify that returning
FeeResult::default()in this error scenario aligns with how fees are calculated upstream.
62-68: ReturningDocumentAction::DeleteActionand a default fee result.Double-check whether a delete transition should always yield a zero-fee result, or if future logic might require a different fee calculation.
packages/rs-dpp/src/document/extended_document/v0/mod.rs (12)
14-14: Maintaining consistency with Document imports.No issues with adding
DocumentV0GettersalongsideDocument; it aligns with usage in this file.
43-43: Added import forTokenPaymentInfo.Bringing the
TokenPaymentInfotype indicates the struct now supports token payment data.
123-131: Introducedtoken_payment_infofield.The optional field integrates token payment data into
ExtendedDocumentV0, with an appropriate$tokenPaymentInfoserde rename. This looks well-structured.
231-241:from_document_with_additional_infonow acceptstoken_payment_info.Expanding the constructor to include token payment info is consistent. Ensure callers provide the correct argument as needed.
307-315: Extractingtoken_payment_infoinfrom_trusted_platform_value.This optional field extraction is handled with graceful error propagation. The approach
.map(|map| map.try_into()).transpose()?is idiomatic in Rust.
330-331: Passingtoken_payment_infotoExtendedDocumentV0.No issues; the struct assignment is clean.
366-374: Extractingtoken_payment_infoinfrom_untrusted_platform_value.Again,
.map(|map| map.try_into()).transpose()?is a neat pattern for conditional parsing. Looks good.
399-400: Assigningtoken_payment_infoafter untrusted parse.Straightforward usage—no concerns.
432-438: Inline conversion oftoken_payment_infoto JSON into_pretty_json.Converting the token payment info to platform
Valuebefore JSON is a sensible approach.
453-458: Populatingtoken_payment_infointo_map_value.Placing
token_payment_infointo the returned map is consistent with the rest of the code.
468-469: Includingtoken_payment_infoininto_map_value.No logical issues—this ensures the info is preserved on conversion.
482-487: Conditional insertion oftoken_payment_infoininto_map_value.The if-let pattern is properly implemented.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/dpns.rs (1)
217-217: AddedNonefor the new argument innew_document_creation_transition_from_document.Passing
Noneappears to match the optional parameter’s expanded signature, likely for token-related data or a function pointer. If no token payment info or special transform is needed here, this is fine. Confirm consistency with the rest of the codebase.Also applies to: 239-239, 261-261, 283-283, 304-304, 325-325, 678-678, 700-700, 722-722, 744-744, 765-765, 786-786
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/mod.rs (7)
33-33: Added necessary import for TokenPaymentInfoThis import aligns with the PR objective to enhance payment processes for NFTs/documents by introducing token payment information functionality.
84-84: Correctly added token payment info to document creation transitionThe addition of the
token_payment_infoparameter to the document creation transition method enables specifying optional token payment information, which is properly passed to both v0 and v1 implementations.Also applies to: 106-106, 122-122
145-145: Added token payment support for replacement transitionsThe token payment parameter is consistently integrated into the document replacement method, maintaining proper parameter ordering and passing it through to both v0 and v1 batch transitions.
Also applies to: 166-166, 181-181
207-207: Added token payment support for transfer transitionsToken payment information is correctly integrated into document transfer transitions, allowing for customized payment options during ownership transfers.
Also applies to: 229-229, 245-245
270-270: Added token payment support for deletion transitionsToken payment support is properly added to document deletion transitions, enabling potential compensation or fee handling during document deletion operations.
Also applies to: 291-291, 306-306
331-331: Added token payment support for price update transitionsThe inclusion of token payment information in price update transitions aligns with the PR's goal of enhancing payment flexibility for document operations.
Also applies to: 353-353, 369-369
396-396: Added token payment support for purchase transitionsToken payment information is correctly added to purchase transitions, which is particularly relevant for the core functionality described in the PR objectives around NFT/document purchases.
Also applies to: 419-419, 436-436
packages/rs-dpp/src/data_contract/document_type/accessors/v1/mod.rs (2)
1-1: Added import for DocumentActionTokenCostThis import provides the structured token cost type that replaces the previous tuple representation, enhancing type safety and readability.
48-85: Added comprehensive setter traitThe new
DocumentTypeV1Setterstrait adds well-documented methods for setting token costs, providing a clean interface for modifying token costs for different document operations.This addition completes the structure by providing both getters and setters for token costs, enabling proper encapsulation of token cost data in document types.
packages/rs-dpp/src/document/specialized_document_factory/v0/mod.rs (8)
36-36: Added TokenPaymentInfo importThis import adds support for the token payment feature in the document factory.
203-203: Initialize token_payment_info to None in ExtendedDocumentV0Both instances of ExtendedDocumentV0 creation are properly updated to include token_payment_info with a default of None, maintaining backward compatibility.
Also applies to: 336-336
216-226: Updated create_state_transition to support token paymentsThe method signature and document handling code are correctly modified to incorporate token payment information in the document creation process.
Also applies to: 240-240
247-247: Fixed owner ID validation for token payment infoThe owner ID validation code is properly updated to handle the new tuple structure including token payment information.
Also applies to: 254-255
271-273: Updated transition processing for delete and replace actionsThe code correctly transforms document tuples to include token payment information when processing delete and replace actions.
Also applies to: 281-283
407-449: Updated document_create_transitions to support token paymentsThe document creation transition method now properly handles token payment information, passing it to the DocumentCreateTransition when creating new documents.
453-496: Updated document_replace_transitions to support token paymentsThe document replacement transition method correctly integrates token payment information, maintaining proper parameter ordering and error handling.
538-575: Updated document_delete_transitions to support token paymentsThe document deletion transition method properly includes token payment information, ensuring that payment details can be specified during document deletion operations.
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/v0/mod.rs (1)
25-25: Added TokenPaymentInfo importThis import adds support for the token payment feature in the document batch transition methods.
packages/rs-dpp/src/data_contract/document_type/token_costs/accessors.rs (3)
1-1: Good use of a dedicated type instead of tuples.The change to import and use
DocumentActionTokenCostinstead of tuples improves type safety and code clarity.
6-6: Refactoring tuple returns to proper type is a good improvement.Changing the return types from
Option<(TokenContractPosition, TokenAmount)>toOption<DocumentActionTokenCost>for all document action cost getters improves code maintainability and readability.Also applies to: 9-9, 12-12, 15-15, 18-18, 21-21
27-27: Consistent type usage in setter methods.The parameter types for setters have been updated to match the getter return types, maintaining API consistency.
Also applies to: 30-30, 33-33, 36-36, 39-39, 42-42
packages/rs-dpp/src/document/document_factory/v0/mod.rs (13)
37-37: Added required import for TokenPaymentInfo.This import supports the new feature for token payment information in document state transitions.
195-196: Initialized TokenPaymentInfo field to None in extended documents.Correctly set default value for the new field in ExtendedDocumentV0 struct initializations.
Also applies to: 327-328
212-219: Updated tuple structure to include TokenPaymentInfo.The signature change adds token payment information to document transitions, supporting the PR objective to enhance payment processes.
Also applies to: 225-229
232-234: Updated pattern matching for the new tuple structure.The code correctly handles the new TokenPaymentInfo field in error checking.
238-240: Updated iterator in ownership validation.Pattern matching has been appropriately updated to account for the new tuple structure.
262-266: Correctly maps document transitions with token payment info.The restructuring properly passes token payment information to the appropriate document transition methods.
Also applies to: 272-276
398-406: Added token payment support to create transitions.Document create transitions now include optional token payment information, properly propagating it to the transition creation.
429-430: Token payment info flows through to DocumentCreateTransition.Properly passing the payment info to the transition creation ensures it will be available in later processing stages.
444-452: Added token payment support to replace transitions.Replace transitions now include token payment information with appropriate error handling for immutable documents.
475-476: Token payment info flows through to DocumentReplaceTransition.The payment information is correctly passed to the transition creation method.
529-537: Added token payment support to delete transitions.Delete transitions now include token payment information with appropriate error handling for indelible documents.
556-557: Token payment info flows through to DocumentDeleteTransition.The payment information is correctly passed to the transition creation method.
624-625: Updated test case to match new function signature.Tests have been updated to include the TokenPaymentInfo parameter (as None), maintaining test functionality.
packages/rs-dpp/src/data_contract/document_type/v1/accessors.rs (4)
1-3: Added import for DocumentTypeV0MutGetters.Properly imported the trait that will be implemented for DocumentTypeV1.
19-19: Updated import for DocumentActionTokenCost.Switched to the new type that replaces the tuple structure for token costs.
23-27: Added mutable schema access to DocumentTypeV1.Implementing DocumentTypeV0MutGetters provides consistent mutable access to the schema across document type versions.
133-135: Updated return types to use DocumentActionTokenCost.All token cost getter methods now return the dedicated type instead of tuples, improving type safety and consistency.
Also applies to: 137-139, 141-143, 145-147, 149-151, 153-155
packages/rs-dpp/src/data_contract/document_type/accessors/mod.rs (6)
18-18: Added import for DocumentActionTokenCost.Properly imported the new type used throughout token cost methods.
24-31: Added schema_mut implementation for DocumentType.This implementation provides mutable access to the schema for both V0 and V1 document types, enhancing API consistency.
206-212: Added DocumentTypeV1Setters implementation with creation token cost.The implementation correctly handles versioning by performing a no-op for V0 and delegating to V1 implementations for V1 document types.
214-247: Implemented remaining token cost setters with version handling.All token cost setter methods follow the same pattern of no-op for V0 and delegation for V1, maintaining consistent behavior across document type versions.
587-592: Updated DocumentType token cost getters to use DocumentActionTokenCost.The implementation correctly returns None for V0 document types and delegates to V1 implementation for V1 types, with proper return type.
Also applies to: 594-599, 601-606, 608-613, 615-620, 622-627
631-636: Consistent token cost getter implementations for references.All variant implementations (DocumentTypeRef and DocumentTypeMutRef) follow the same pattern, ensuring consistent behavior across reference types.
Also applies to: 638-643, 645-650, 652-657, 659-664, 666-671, 675-680, 682-687, 689-694, 696-701, 703-708, 710-715
packages/rs-dpp/src/data_contract/document_type/token_costs/mod.rs (13)
5-5: Import usage looks good.
ImportingDocumentActionTokenCostis necessary for this file's new return types and setters, and it's cleanly integrated.
20-24: Transition toDocumentActionTokenCostfor creation cost is consistent.
ReturningOption<DocumentActionTokenCost>enhances clarity over the old tuple form. Implementation aligns well with the versioned enum.
26-30: Consistent approach for replacement cost.
Same pattern as creation cost; switching toOption<DocumentActionTokenCost>is coherent.
32-36: Removal cost refactor is logical.
Matches the new encapsulatedDocumentActionTokenCoststructure.
38-42: Transfer cost usage updated.
No issues found; approach is uniform with other token cost methods.
44-48: Price update cost method adjusted properly.
Switching to anOption<DocumentActionTokenCost>return is consistent.
50-54: Purchase cost getter refactored.
The new method signature is aligned with the rest of the code.
58-62: Setter for creation token cost updated.
SettingOption<DocumentActionTokenCost>ensures consistency across the type.
64-68: Setter for replacement token cost is coherent.
Implementation follows the same pattern.
70-74: Setter for deletion cost revised.
No concerns here; code is straightforward and consistent.
76-80: Setter for transfer cost aligns with new approach.
Matches the pattern of other token cost setters.
82-86: Setter for price update cost updated properly.
Implementation is correct and uniform.
88-92: Setter for purchase token cost is consistent.
This completes the migration toDocumentActionTokenCost.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v0/v0_methods.rs (11)
42-42: New import forTokenPaymentInfo.
ImportingTokenPaymentInfois needed for the added optional parameter logic.
89-89: Optionaltoken_payment_infoparameter in creation transition.
Adding this parameter broadens functionality to include token payment details in the creation flow.
131-131: Optionaltoken_payment_infoin replacement transition.
Change mirrors the creation transition approach, maintaining consistent parameter usage.
173-173: Optional parameter in transfer transition.
The approach is coherent with the newly introduced token payment logic.
185-185: Passingtoken_payment_infotoDocumentTransferTransition::from_document.
Ensures the token payment info is correctly forwarded to underlying logic.
215-215: Optionaltoken_payment_infoin deletion transition.
Maintains consistency across all document transitions.
226-226: Forwardingtoken_payment_infoto deletion logic.
Implementation remains uniform across transitions.
257-257: Parameter for update price transition.
Facilitates token payment details for price updates.
269-269: Injectingtoken_payment_infowhen creating the update price transition.
Ensures the same pattern is followed across transition factories.
301-301: Optional parameter for purchase transition.
Supports token payment details for document purchase transitions.
313-313: Passingtoken_payment_infotoDocumentPurchaseTransition::from_document.
Completes the integration of token payment info for purchase operations.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs (10)
88-88: ImportingTokenPaymentInfofor V1 transitions.
Enables expanded payment logic in version 1 transitions.
137-137: New optionaltoken_payment_infoparameter in creation transition (V1).
Continues the token payment info pattern for V1.
179-179: Parameter for replacement transition in V1.
Keeps consistent signature across doc transitions.
191-191: Forwardingtoken_payment_infotoDocumentReplaceTransition::from_document.
Ensures the new field is properly conveyed.
221-221: Optional parameter in V1 document deletion transition.
Aligns with the newly introduced token payment info logic.
232-232: Passingtoken_payment_infoto deletion transition creation.
Continues the pattern of consistent usage across transitions.
263-263: Parameter for update price transition in V1.
Supports a unified approach for including token payment data.
275-275: Providingtoken_payment_infotoDocumentUpdatePriceTransition::from_document.
Maintains uniform usage in the codebase.
349-349: Optional parameter in purchase transition (V1).
Expands the purchase transition to account for token payment details.
360-360: Passingtoken_payment_infowhen constructing purchase transition.
Ensures the logic is fully integrated with new token payment flows.packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/v1/v1_methods.rs (4)
1-5: New file introduction for V1 base transitions.
These imports and definitions set the foundation for handling token payment info inDocumentBaseTransitionV1.
7-20:DocumentBaseTransitionV1Methodstrait definition.
Establishes clear getters/setters fortoken_payment_info. This is a solid extension of existing V0 methods.
22-38: Implementation ofDocumentBaseTransitionV1MethodsforDocumentBaseTransitionV1.
Provides straightforward logic for storing and clearingtoken_payment_info. Nicely consistent with the introduced trait.
40-80: V0 methods implementation in a V1 struct to maintain backward compatibility.
This ensuresDocumentBaseTransitionV1supports older functionalities while adding new token payment info. The approach is clear and well-structured.packages/rs-dpp/src/data_contract/document_type/token_costs/v0/mod.rs (5)
4-4: Updated import to use DocumentActionTokenCostThe import has been correctly updated to use the new
DocumentActionTokenCosttype instead of the previous tuple approach. This is consistent with the PR objectives to enhance token payment information handling.
10-10: Refactored token cost fields to use more structured typeAll token cost fields have been properly updated to use
Option<DocumentActionTokenCost>instead of the previous tuple representation. This change provides more structure and clarity to the token cost model, allowing for more flexible token payment handling as described in the PR objectives.Also applies to: 13-13, 16-16, 19-19, 22-22, 25-25
30-32: Updated getter methods to return the new DocumentActionTokenCost typeThe getter methods have been properly updated to return
Option<DocumentActionTokenCost>, which aligns with the field type changes. This ensures type consistency throughout the codebase.Also applies to: 34-36, 38-40, 42-44, 46-48, 50-52
57-59: Updated setter methods to accept the new DocumentActionTokenCost typeThe setter methods have been properly updated to accept
Option<DocumentActionTokenCost>, maintaining consistency with the corresponding field types and getter methods.Also applies to: 61-63, 65-67, 69-71, 73-75, 77-79
1-80:❓ Verification inconclusive
Verify backward compatibility and migration plan
This change replaces the tuple representation
(TokenContractPosition, TokenAmount)withDocumentActionTokenCostthroughout the codebase, which is a breaking change as mentioned in the PR objectives.Since this is marked as a breaking change in the PR description, ensure there's a clear migration guide for users of this API to update their code accordingly.
🏁 Script executed:
#!/bin/bash # Look for any possible usages of the old tuple format that might need updating # Search for patterns that might indicate direct tuple usage for token costs echo "Searching for potential usages of the old TokenContractPosition, TokenAmount tuple pattern..." rg -n "TokenContractPosition.*TokenAmount" --type rustLength of output: 253
Please verify that a detailed migration guide is provided
- Our search confirmed that there are no remaining references to the old
(TokenContractPosition, TokenAmount)tuple in the codebase.- Since the change to
DocumentActionTokenCostis breaking, please ensure that users have a clear migration guide explaining how to update their integration with the new API.
...nsitions/document/batch_transition/batched_transition/document_base_transition/v1_methods.rs
Show resolved
Hide resolved
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs
Outdated
Show resolved
Hide resolved
...abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (1)
559-614: Refactorunwrap()afteris_some()check for better safety and style.The code correctly implements the token payment validation logic, but there's an unnecessary unwrap pattern that could be improved.
- if contract_id.is_some() && effect == DocumentActionTokenEffect::BurnToken { - return Err(ProtocolError::ConsensusError( - ConsensusError::BasicError( - BasicError::TokenPaymentByBurningOnlyAllowedOnInternalTokenError( - TokenPaymentByBurningOnlyAllowedOnInternalTokenError::new( - contract_id.unwrap(), - token_contract_position, - key.to_string(), - ), - ), - ) - .into(), - )); - } + if let Some(external_contract_id) = contract_id { + if effect == DocumentActionTokenEffect::BurnToken { + return Err(ProtocolError::ConsensusError( + ConsensusError::BasicError( + BasicError::TokenPaymentByBurningOnlyAllowedOnInternalTokenError( + TokenPaymentByBurningOnlyAllowedOnInternalTokenError::new( + external_contract_id, + token_contract_position, + key.to_string(), + ), + ), + ) + .into(), + )); + } + }🧰 Tools
🪛 GitHub Check: Rust packages (dpp) / Linting
[failure] 587-587: called
unwraponcontract_idafter checking its variant withis_some
error: calledunwraponcontract_idafter checking its variant withis_some
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:587:45
|
582 | if contract_id.is_some() && effect == DocumentActionTokenEffect::BurnToken {
| --------------------- the check is happening here
...
587 | contract_id.unwrap(),
| ^^^^^^^^^^^^^^^^^^^^
|
= help: try usingif letormatch
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_unwrap
= note:-D clippy::unnecessary-unwrapimplied by-D warnings
= help: to override-D warningsadd#[allow(clippy::unnecessary_unwrap)]packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (2)
16-50: Fix documentation indentation for list item.The struct definition is well-structured with appropriate attributes and documentation for most fields. However, there's a documentation formatting issue on line 45.
- /// Then: + /// Then:Static analysis found this issue: "doc list item without indentation" at line 45.
🧰 Tools
🪛 GitHub Check: Rust packages (dpp) / Linting
[failure] 45-45: doc list item without indentation
error: doc list item without indentation
--> packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs:45:9
|
45 | /// Then:
| ^
|
= help: if this is supposed to be its own paragraph, add a blank line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
= note:-D clippy::doc-lazy-continuationimplied by-D warnings
= help: to override-D warningsadd#[allow(clippy::doc_lazy_continuation)]
help: indent this line
|
45 | /// Then:
| ++
100-126: Consider adding error handling for invalid gas fees payer strings.The
TryFromimplementation for converting from aBTreeMaptoTokenPaymentInfoV0silently defaults to the defaultGasFeesPaidByvalue when an invalid string is provided. This could hide errors in the input data.Consider returning an error for invalid
gasFeesPaidByvalues:gas_fees_paid_by: map .remove_optional_string("gasFeesPaidBy")? .map(|v| match v.as_str() { "DocumentOwner" => GasFeesPaidBy::DocumentOwner, "ContractOwner" => GasFeesPaidBy::ContractOwner, "PreferContractOwner" => GasFeesPaidBy::PreferContractOwner, - _ => GasFeesPaidBy::default(), + invalid_value => return Err(ProtocolError::Generic(format!("Invalid gasFeesPaidBy value: {}", invalid_value))), }) .unwrap_or_default(),Or document that invalid values will be replaced with the default.
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (2)
22-41: Consider adding documentation for the TokenPaymentInfo enum.The enum definition has appropriate derive attributes and feature-gated serialization, but lacks documentation that would help users understand its purpose and usage.
Add documentation to the enum:
+/// Represents token payment information with versioning support. +/// Currently only supports version 0. #[derive( Debug, Clone, Copy, Encode, Decode, PlatformDeserialize, PlatformSerialize, PartialEq, Display, From, )] #[cfg_attr( feature = "state-transition-serde-conversion", derive(Serialize, Deserialize) )] pub enum TokenPaymentInfo { + /// Version 0 of token payment information. #[display("V0({})", "_0")] V0(TokenPaymentInfoV0), }
43-43: Empty trait implementation could use a comment.The empty implementation of
TokenPaymentInfoMethodsV0forTokenPaymentInfoshould have a comment explaining why it's empty or what it provides.+// Implementing this trait signals that this type supports version 0 methods impl TokenPaymentInfoMethodsV0 for TokenPaymentInfo {}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
packages/check-features/src/main.rs(1 hunks)packages/rs-dpp/src/core_types/validator_set/v0/mod.rs(2 hunks)packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs(2 hunks)packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs(4 hunks)packages/rs-dpp/src/errors/consensus/basic/json_schema_error/error.rs(2 hunks)packages/rs-dpp/src/errors/consensus/basic/json_schema_error/error_data.rs(1 hunks)packages/rs-dpp/src/identity/identity_factory.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/convertible.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/mod.rs(19 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/v0/mod.rs(7 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v0/v0_methods.rs(13 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs(13 hunks)packages/rs-dpp/src/tokens/gas_fees_paid_by.rs(1 hunks)packages/rs-dpp/src/tokens/token_payment_info/mod.rs(1 hunks)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- packages/rs-dpp/src/core_types/validator_set/v0/mod.rs
- packages/check-features/src/main.rs
🚧 Files skipped from review as they are similar to previous changes (6)
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/convertible.rs
- packages/rs-dpp/src/tokens/gas_fees_paid_by.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v0/v0_methods.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/v0/mod.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/v1/v0_methods.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/methods/mod.rs
🧰 Additional context used
🧬 Code Definitions (4)
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs (2)
packages/rs-dpp/src/data_contract/document_type/class_methods/create_document_types_from_document_schemas/v0/mod.rs (1)
data_contract(14-61)packages/rs-dpp/src/data_contract/document_type/class_methods/create_document_types_from_document_schemas/v1/mod.rs (1)
data_contract(15-63)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (2)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (12)
gas_fees_paid_by(91-93)payment_token_contract_id(54-56)payment_token_contract_id_ref(58-60)token_contract_position(62-64)minimum_token_cost(66-68)maximum_token_cost(70-72)set_payment_token_contract_id(75-77)set_token_contract_position(79-81)set_minimum_token_cost(83-85)set_maximum_token_cost(87-89)set_gas_fees_paid_by(95-97)try_from(103-125)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (11)
gas_fees_paid_by(38-38)payment_token_contract_id(9-9)payment_token_contract_id_ref(14-14)token_contract_position(17-17)minimum_token_cost(20-20)maximum_token_cost(23-23)set_payment_token_contract_id(26-26)set_token_contract_position(29-29)set_minimum_token_cost(32-32)set_maximum_token_cost(35-35)set_gas_fees_paid_by(41-41)
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (3)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (2)
gas_fees_paid_by(91-93)token_contract_position(62-64)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (2)
gas_fees_paid_by(38-38)token_contract_position(17-17)packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs (1)
new(23-33)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (3)
packages/rs-dpp/src/tokens/token_payment_info/mod.rs (7)
gas_fees_paid_by(102-106)payment_token_contract_id(47-51)token_contract_position(59-63)minimum_token_cost(65-69)maximum_token_cost(71-75)try_from(118-134)try_from(140-142)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (5)
gas_fees_paid_by(38-38)payment_token_contract_id(9-9)token_contract_position(17-17)minimum_token_cost(20-20)maximum_token_cost(23-23)packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (2)
try_from(39-51)try_from(57-68)
🪛 GitHub Check: Rust packages (dpp) / Linting
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs
[failure] 587-587: called unwrap on contract_id after checking its variant with is_some
error: called unwrap on contract_id after checking its variant with is_some
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:587:45
|
582 | if contract_id.is_some() && effect == DocumentActionTokenEffect::BurnToken {
| --------------------- the check is happening here
...
587 | contract_id.unwrap(),
| ^^^^^^^^^^^^^^^^^^^^
|
= help: try using if let or match
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_unwrap
= note: -D clippy::unnecessary-unwrap implied by -D warnings
= help: to override -D warnings add #[allow(clippy::unnecessary_unwrap)]
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs
[failure] 45-45: doc list item without indentation
error: doc list item without indentation
--> packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs:45:9
|
45 | /// Then:
| ^
|
= help: if this is supposed to be its own paragraph, add a blank line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
= note: -D clippy::doc-lazy-continuation implied by -D warnings
= help: to override -D warnings add #[allow(clippy::doc_lazy_continuation)]
help: indent this line
|
45 | /// Then:
| ++
⏰ Context from checks skipped due to timeout of 90000ms (19)
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Detect immutable structure changes
- GitHub Check: Rust packages (drive) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (wasm-dpp) / Formatting
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Unused dependencies
- GitHub Check: Rust packages (rs-dapi-client) / Tests
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (19)
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v0/mod.rs (2)
11-13: Well-structured conditional importThe code now conditionally imports
DocumentPropertyTypeonly when the "validation" feature is enabled, while keepingDocumentPropertyunconditionally imported. This is a good practice sinceDocumentPropertyTypeis only used within code blocks that are already wrapped with#[cfg(feature = "validation")](specifically in the property type validation at lines 444-499).
37-37: Consistent feature flag usageAdding the conditional compilation flag to this import improves consistency, as these constants are only used within validation code blocks.
packages/rs-dpp/src/errors/consensus/basic/json_schema_error/error_data.rs (1)
9-12: Added missing imports for existing functionality.The added imports for
std::fmt::Writeandstd::ops::Derefare correctly guarded with the conditional compilation flag. These traits are already being used in the codebase (e.g., line 31 withwrite!and lines 152/158 withderef()), so this change properly declares dependencies that were previously implicit.packages/rs-dpp/src/errors/consensus/basic/json_schema_error/error.rs (2)
1-2: Properly conditionalized import for JSON schema validation.Good improvement to properly isolate the
JsonSchemaErrorDataimport behind the feature flag, ensuring it's only included when the JSON schema validation feature is enabled.
11-12: Added conditionally compiled alias for JSON Value.The addition of
serde_json::Value as JsonValuewith proper feature flag isolation is a good improvement. This alias helps distinguish from theplatform_value::Valuealready in use (line 10) and is correctly used in the implementation at line 49.packages/rs-dpp/src/identity/identity_factory.rs (1)
26-30:✅ Verification successful
Feature flag dependency change aligns with token payment info refactoring
The conditional compilation attribute for
IdentityPlatformValueConversionMethodsV0has been updated from requiring "validation" and "identity-value-conversion" features to now requiring "identity-serialization", "client", and "validation" features. This change appears to be part of the broader token payment information refactoring mentioned in the PR objectives.This modification suggests a more focused approach to feature organization, making the identity conversion functionality available specifically in client contexts where serialization is needed. This aligns with the PR's goal of enhancing the payment process for NFTs/documents.
🏁 Script executed:
#!/bin/bash # Verify that there are no remaining direct references to "identity-value-conversion" feature that might be affected by this change echo "Checking for remaining references to identity-value-conversion feature that might be affected..." rg -l "identity-value-conversion" --type rust | grep -v "identity_factory.rs" | xargs grep -l "IdentityPlatformValueConversionMethodsV0" || echo "No problematic references found." echo "Checking for possible usages of this module with the new feature flags..." rg -A 3 -B 3 "IdentityPlatformValueConversionMethodsV0" --type rustLength of output: 4730
Verified: Identity Conversion Feature Flag Update is Correct
- The conditional compilation attribute in
packages/rs-dpp/src/identity/identity_factory.rshas been successfully updated to require"identity-serialization","client", and"validation", aligning with the token payment information refactoring.- Verification confirms that no residual references to the removed
"identity-value-conversion"feature affectIdentityPlatformValueConversionMethodsV0.- Usage in the related modules (e.g., in
packages/rs-dpp/src/identity/v0/conversion/platform_value.rsand others) remains correct under the new feature configuration.packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (7)
11-13: LGTM: Added imports for document property types.These imports are necessary for the new token payment functionality and are correctly scoped with feature flags where appropriate.
32-32: LGTM: Added import for TokenPaymentByBurningOnlyAllowedOnInternalTokenError.This import is correctly scoped with the validation feature flag and will be used for validating token burning restrictions.
61-64: LGTM: Added imports for token-related types.These imports support the new token payment features, importing
GasFeesPaidByandDocumentActionTokenCost/DocumentActionTokenEffecttypes that are essential for the enhanced token payment functionality.
559-564: LGTM: Enhanced token cost extraction to support the new token payment features.The
extract_costfunction has been properly updated to return the more comprehensiveDocumentActionTokenCoststructure instead of a simple tuple. This aligns well with the PR's goal of enhancing the payment process for NFTs/documents.
565-576: LGTM: Comprehensive token payment property extraction.The code correctly extracts all required properties for token payments: contract ID (for external tokens), token position, amount, and effect (transfer or burn). The default effect of
TransferTokenToContractOwneraligns with the PR requirements that external tokens can only be transferred to the contract owner.
578-596: LGTM: Validates that external tokens cannot be burned.This validation correctly implements the business rule that "payments made with external tokens can only be transferred to the contract owner, while payments made with internal tokens can either be transferred to the contract owner or burned."
🧰 Tools
🪛 GitHub Check: Rust packages (dpp) / Linting
[failure] 587-587: called
unwraponcontract_idafter checking its variant withis_some
error: calledunwraponcontract_idafter checking its variant withis_some
--> packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs:587:45
|
582 | if contract_id.is_some() && effect == DocumentActionTokenEffect::BurnToken {
| --------------------- the check is happening here
...
587 | contract_id.unwrap(),
| ^^^^^^^^^^^^^^^^^^^^
|
= help: try usingif letormatch
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_unwrap
= note:-D clippy::unnecessary-unwrapimplied by-D warnings
= help: to override-D warningsadd#[allow(clippy::unnecessary_unwrap)]
599-611: LGTM: Gas fees payment handling.The implementation correctly extracts the
gasFeesPaidByproperty with a default toDocumentOwner, supporting the new field mentioned in the PR objectives "to determine who will pay the fees associated with state transitions that require token payments."packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (2)
1-15: Module structure and imports look good.The file is well-organized with clear and appropriate imports. The conditional imports for serde are correctly handled with feature flags.
52-98: Implementation of accessors looks good.The implementation of the
TokenPaymentInfoAccessorsV0trait provides straightforward getters and setters for all fields, which is appropriate for this data structure.packages/rs-dpp/src/tokens/token_payment_info/mod.rs (4)
1-21: Module imports and structure are appropriate.The imports are well-organized and the module structure with submodules for methods and version-specific implementations is a good design.
45-113: Accessor implementations are correctly forwarded to the inner type.The implementation of
TokenPaymentInfoAccessorsV0forTokenPaymentInfocorrectly delegates all method calls to the wrappedTokenPaymentInfoV0instance. This is a good pattern for maintaining the version-specific behavior while providing a unified interface.
115-135: Version handling in TryFrom implementation is robust.The implementation of
TryFrom<BTreeMap<String, Value>>forTokenPaymentInfocorrectly handles versioning with proper error messages for unknown versions. The format version is extracted from the input map and used to determine how to parse the rest of the data.
137-143: Value conversion implementation is appropriate.The conditional implementation of
TryFrom<TokenPaymentInfo>forValuewhen the "state-transition-value-conversion" feature is enabled correctly uses the platform serialization functionality.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs (1)
66-91: Consider standardizing the fallback messages for consistency.The error formatting is thorough, but there's an inconsistency in the fallback strings: "Not Expected" vs "Not Set". Consider standardizing these messages for better clarity.
- Some(id) => format!("{}", id), - None => "Not Expected".to_string(), + Some(id) => format!("{}", id), + None => "None".to_string(), - Some(id) => format!("{}", id), - None => "Not Set".to_string(), + Some(id) => format!("{}", id), + None => "None".to_string(),Alternatively, if the distinction is intentional, consider adding a comment explaining the different semantics.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
packages/rs-dpp/src/data_contract/document_type/class_methods/mod.rs(1 hunks)packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/from_document.rs(2 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/from_document.rs(2 hunks)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (8)
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transfer_transition/from_document.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_base_transition/from_document.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_delete_transition/from_document.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_update_price_transition/from_document.rs
- packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/from_document.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_purchase_transition/from_document.rs
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_replace_transition/from_document.rs
⏰ Context from checks skipped due to timeout of 90000ms (20)
- GitHub Check: Rust packages (dash-sdk) / Formatting
- GitHub Check: Rust packages (rs-dapi-client) / Unused dependencies
- GitHub Check: Rust packages (rs-dapi-client) / Tests
- GitHub Check: Rust packages (rs-dapi-client) / Check each feature
- GitHub Check: Rust packages (dapi-grpc) / Formatting
- GitHub Check: Rust packages (dapi-grpc) / Tests
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (dapi-grpc) / Linting
- GitHub Check: Rust packages (drive-abci) / Unused dependencies
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (dpp) / Check each feature
- 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 Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (5)
packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs (4)
9-19: Well-structured error type for token payment validation.This new error struct captures all the necessary information to diagnose token payment issues, including expected and actual contract IDs, token positions, and token IDs. The trait derivations are appropriate for an error type that needs serialization support.
21-39: Constructor implementation is appropriate with proper attribute.The
#[allow(clippy::too_many_arguments)]attribute is justified here since all parameters are necessary to fully describe the error condition. The struct fields are initialized in a clean, straightforward manner.
41-63: Accessor methods follow Rust best practices.The getter methods correctly return either owned values (for
Option<Identifier>) or references (for plainIdentifiertypes) to avoid unnecessary cloning. The method names clearly indicate their purpose.
93-99: Proper error trait implementations for integration with consensus module.The implementation of
std::error::Errorand the conversion toConsensusErrorfollow best practices for Rust error handling, enabling smooth integration with the existing error hierarchy.packages/rs-dpp/src/data_contract/document_type/class_methods/mod.rs (1)
37-37:✅ Verification successful
Error handling has been modified - please verify this change.
The error handling in
consensus_or_protocol_value_errorhas been changed to directly pass theplatform_value_errortoProtocolError::ValueErrorinstead of using.into()for conversion. While this likely simplifies the code, it's important to verify thatProtocolError::ValueErrorcorrectly accepts aplatform_value::Errordirectly.
🏁 Script executed:
#!/bin/bash # Check the definition of ProtocolError to verify ValueError variant accepts platform_value::Error directly rg "enum ProtocolError" -A 20 --context 3Length of output: 566
I'm going to run a further verification to ensure that the
ProtocolError::ValueErrorvariant exists and that it indeed accepts aplatform_value::Errordirectly.
🏁 Script executed:
#!/bin/bash # Search for the ValueError variant in the ProtocolError enum to confirm its type signature rg "ValueError" packages/rs-dpp/src/errors/protocol_error.rsLength of output: 146
Change Verified: Error Handling is Correct
The updated usage of
ProtocolError::ValueError(platform_value_error)is valid. Our verification confirms that theValueErrorvariant inProtocolErrordirectly accepts aplatform_value::Errorinstance.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (1)
18-19: Silencingclippy::too_many_arguments.
The updated function signature adds multiple parameters, reflecting new logic for ownership and fees. Consider factoring repetitive arguments into a dedicated struct if the method continues to grow in complexity.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs (1)
26-26: Suppressingclippy::too_many_arguments.
As with the other file, consider a refactor to group the arguments if this function signature becomes unwieldy.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_transfer_transition_action/v0/transformer.rs (1)
26-26: New parameteruser_fee_increase.
Enables dynamic fee escalation. Validate if an unreasonably high value could pose a risk.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/v0/transformer.rs (2)
47-52: Action context “replace” seems correct.Passing
"replace"totry_from_borrowed_base_transition_with_contract_lookupaccurately denotes the current transition. If you standardize these action names across similar transitions, ensure consistency for better traceability.
97-117: Consider incorporating user fee logic into the final FeeResult.Currently, the
FeeResultis defaulted toFeeResult::default()regardless ofuser_fee_increase. If additional fees or adjustments should be applied at document replacement time, factor that into the returnedFeeResult. Otherwise, confirm that the fee logic is handled elsewhere.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs(4 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/deletion.rs(16 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/nft.rs(34 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/replacement.rs(25 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/transfer.rs(14 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.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(1 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/mod.rs(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/transfer.rs
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/nft.rs
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/replacement.rs
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/deletion.rs
🧰 Additional context used
🧬 Code Definitions (3)
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (3)
packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (2)
gas_fees_paid_by(91-93)token_contract_position(62-64)packages/rs-dpp/src/tokens/token_payment_info/v0/v0_accessors.rs (2)
gas_fees_paid_by(38-38)token_contract_position(17-17)packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs (1)
new(23-33)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (2)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs (1)
try_from_document_borrowed_create_transition_with_contract_lookup(14-29)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs (1)
try_from_borrowed_document_create_transition_with_contract_lookup(27-157)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_purchase_transition_action/v0/transformer.rs (2)
packages/rs-dpp/src/document/extended_document/v0/mod.rs (2)
owner_id(159-161)document_type(163-168)packages/rs-dpp/src/document/extended_document/accessors.rs (2)
owner_id(35-39)document_type(46-50)
⏰ Context from checks skipped due to timeout of 90000ms (19)
- GitHub Check: Rust packages (dash-sdk) / Formatting
- GitHub Check: Rust packages (rs-dapi-client) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Detect immutable structure changes
- GitHub Check: Rust packages (rs-dapi-client) / Formatting
- GitHub Check: Rust packages (rs-dapi-client) / Unused dependencies
- GitHub Check: Rust packages (rs-dapi-client) / Linting
- GitHub Check: Rust packages (dapi-grpc) / Formatting
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (dapi-grpc) / Tests
- GitHub Check: Rust packages (dapi-grpc) / Linting
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (57)
packages/rs-drive/src/state_transition_action/batch/batched_transition/mod.rs (5)
3-3: Added import for error handling.The addition of the
ProtocolErrorimport is necessary to support the new error handling in the accessor methods. This aligns with the PR's objective to enhance validation for token payments.
41-50: Well-implemented safe accessor for DocumentAction variant.This method provides type-safe access to the
DocumentActionvariant with proper error handling, which is critical for robust token payment processing. The implementation follows best practices by returning aResulttype and providing descriptive error messages.
52-61: Well-implemented safe accessor for TokenAction variant.This method follows the same pattern as
as_document_action, providing type-safe access to theTokenActionvariant. This consistent implementation helps maintain the codebase's readability and predictability.
63-74: Well-implemented safe accessor for BumpIdentityDataContractNonce variant.This method completes the set of accessors for all variants in the enum, ensuring consistent access patterns throughout the codebase. The error handling is appropriate and follows the established pattern.
76-85: Helper method for variant name diagnostics.The
variant_namehelper method is a clean solution for providing consistent variant names in error messages. This improves error diagnostics without duplicating string literals.packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v1/mod.rs (6)
32-32: Good addition of the TokenPaymentByBurningOnlyAllowedOnInternalTokenError import.This error type is correctly imported under the validation feature flag and will be used to enforce the rule that external tokens cannot be burned.
61-64: Nice job adding the necessary imports for token payment functionality.These imports add support for the new token payment features, including gas fee handling and token effects (burn vs. transfer).
559-616: Good implementation of enhanced token payment processing.The refactored
extract_costfunction correctly handles the expanded token payment information structure:
- Now returns a
DocumentActionTokenCostinstead of a tuple- Extracts the optional contract ID for external tokens
- Properly enforces that only internal tokens can be burned
- Sets appropriate defaults for the token effect and gas fees payer
This implementation aligns well with the PR objective to support different token payment behaviors.
582-597: Excellent validation to prevent burning external tokens.This validation enforces an important business rule: burning tokens is only allowed for internal tokens, not for external tokens which can only be transferred to the contract owner.
600-606: Good handling of gas fees payment responsibility.The code correctly extracts the
gasFeesPaidByfield and defaults toDocumentOwnerif not specified, which aligns with the PR objective of adding a field to determine who will pay the fees.
607-613: Well-structured DocumentActionTokenCost construction.All the extracted fields are properly assembled into the
DocumentActionTokenCoststructure, providing a clean and consistent API for token payment information.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/transformer.rs (5)
6-6: Imports look appropriate.
The addition ofConsensusValidationResultandUserFeeIncreasematches the new validation and fee features.
13-13: New import forBatchedTransitionAction.
This import is essential for constructing and returning the batched transition as part of the new method signature. No concerns here.
21-21: New parameterowner_id.
Includingowner_idhelps track the identity responsible for the document transition. Ensure all call sites supply a valid identifier and handle potential errors upstream.
25-25: New parameteruser_fee_increase.
Allows fee escalation for transitions. Confirm that the fee increments are validated or bounded if there's a risk of large or invalid inputs.
37-37: Forwarding to the V0 match arm.
The call intoDocumentCreateTransitionActionV0::try_from_borrowed_document_create_transition_with_contract_lookupappears consistent with the new signature. No immediate concerns.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_create_transition_action/v0/transformer.rs (11)
7-7: ImportingConsensusValidationResultandUserFeeIncrease.
These are key to the updated fee handling and validation changes. This aligns with the broader modification to return a detailed validation result.
18-18: New import statement forBatchedTransitionAction.
Required for the updated return type. The approach is in line with the new design to bundle the transition in a single structured action.
19-21: Imports forDocumentBaseTransitionActionandDocumentTransitionAction.
These are central to constructing and returning the final document transition action. Usage looks correct.
22-22: Adding theBumpIdentityDataContractNonceActionimport.
This import supports the fallback path when validation fails, ensuring we can increment the contract nonce. No controversies here.
29-29: New parameterowner_id.
Inclusion of the owner ID is consistent with the new logic for identity-based actions. Verify that all calls pass the correct owner.
33-33: New parameteruser_fee_increase.
This ties into user-based fee escalation. Validate or cap this value if potential abuse is a concern.
36-42: Method signature return type expansion.
Returning(ConsensusValidationResult<BatchedTransitionAction>, FeeResult)captures both fee computations and validation. This may require updates in related testing or calling contexts.
49-49: Validation result assigned tobase_action_validation_result.
Ensures that we short-circuit upon validation failure. Continue verifying the completeness of these error checks to avoid partial transitions.
54-54: Explicit'create'action context.
Clarity in using'create'as the action label. This helps ensure cost/fee retrieval aligns with a create operation.
57-77: Handling validation failures withBumpIdentityDataContractNonceAction.
The fallback path upon validation failure is well-defined and consistent with the newly introduced logic for dealing with invalid transitions. This flow ensures that we do not proceed with partial or invalid transitions.
79-79: Use of early return for the successful path.
After handling the potential error path, returning the newly createdDocumentCreateTransitionActionV0wrapped in aBatchedTransitionActionis concise. This approach neatly separates error handling from successful outcomes.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_transfer_transition_action/v0/transformer.rs (8)
7-8: Additional imports for fees and validation.
Bringing inFeeResultandConsensusValidationResultaligns with the consistent approach across all transition actions.
12-13: ImportingErrorandBatchedTransitionAction.
Essential for constructing flexible error-handling and batched transitions. No issues.
16-17: New references toDocumentTransitionActionandBumpIdentityDataContractNonceAction.
These support the enhanced fee logic and fallback path when validation fails. Consistent with other transition actions.
23-23: New parameterowner_id.
Ensures the transfer logic can accurately identify which identity is behind the transition and handle nonce actions if needed.
28-34: Expanded return type for transfer transitions.
Consistently returns(ConsensusValidationResult<BatchedTransitionAction>, FeeResult), aligning with the design used in create transitions. Confirm test coverage for both success and failure cases.
40-45: Using'transfer'action label and cost retrieval.
Mirrors the approach indocument_create_transition_actionbut ensures correct cost is tied to a transfer event. No immediate concerns.
48-68: Managing validation failures with aBumpIdentityDataContractNonceAction.
This uniform approach across transitions lets the system gracefully reject invalid transfers while still updating contract nonce. It’s consistent and maintainable.
91-101: Constructing theTransferAction.
After stripping price and bumping revision, the final action is returned with a default fee. This is logical and keeps the document’s transitional state consistent.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/v0/transformer.rs (7)
4-14: No issues with newly introduced imports.
These additions appropriately bring inFeeResult,ConsensusValidationResult,UserFeeIncrease,Error,BatchedTransitionAction,DocumentTransitionAction, andBumpIdentityDataContractNonceAction.
20-21: Parameters added for owner identity and fee handling.
The inclusion ofowner_id: Identifieranduser_fee_increase: UserFeeIncreaseseems consistent with the broader pattern for transitions that handle identity and fee adjustments.
23-29: Refined return type with additional fee result.
Returning(ConsensusValidationResult<BatchedTransitionAction>, FeeResult)provides greater clarity and flexibility for handling outcomes and fees in a single call. This change aligns well with the new approach to manage validation and fee computation together.
32-38: Token cost retrieval logic appears consistent.
Usingdocument_type.document_deletion_token_cost()for the “delete” action fits the newly introduced token-cost approach for each document transition type.
40-42: Validation check on base action.
This condition correctly directs the flow based on the outcome of the base action’s validation result.
43-59: Constructing the bump action on validation failure.
Fallback toBumpIdentityDataContractNonceActionis consistent with the pattern in other transitions. Appropriately returns any errors while preserving the validated batched action.
62-68: Successful action returning default fee result.
Once the base transition is valid, creating aDocumentAction::DeleteActionand pairing it with a defaultFeeResultis correct.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_update_price_transition_action/v0/transformer.rs (6)
7-8: Imports align with new fee handling paradigm.
These additions forFeeResult,ConsensusValidationResult,UserFeeIncrease,Error,BatchedTransitionAction, etc. are consistent with the updated transition model.Also applies to: 12-13, 16-17
23-29: Extended parameters and updated return type.
The addition ofowner_id: Identifieranduser_fee_increase: UserFeeIncreasealong with returning(ConsensusValidationResult<BatchedTransitionAction>, FeeResult)enables thorough fee and validation handling.
36-38: Integration with token cost logic for price updates.
Retrieving cost viadocument_type.document_update_price_token_cost()and labeling the action as "update_price" are clear, consistent expansions of the base transition approach.Also applies to: 40-41
44-46: Conditionally extracting validated base action.
This match pattern ensuring valid base transition data is used or falling back to a bump action is standard across the codebase now.
47-63: Bump action construction on invalid base transition.
Mirrors the logic seen in other transitions, ensuring fees and validation errors are appropriately returned together.
84-94: Document modification logic for price update.
Properly updates the document’s price, revision, and timestamps when required. Returning the default fee result is consistent with other transitions.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_purchase_transition_action/v0/transformer.rs (5)
7-8: Imports for fee and transition actions.
No issues found; these imports align with the new transition structure for fees and validation.Also applies to: 12-13, 16-17
23-23: Extended parameters and fee result return for purchase transition.
Inclusion ofowner_idanduser_fee_increase, plus returning(ConsensusValidationResult<BatchedTransitionAction>, FeeResult), ensures the purchase transition aligns with the consolidated validation-fee approach.Also applies to: 27-27, 29-35
37-37: Applying document type-specific token cost function for purchase.
Appropriately usesdocument_purchase_token_cost()for the “purchase” action, maintaining consistent logic with other transitions.Also applies to: 41-42
45-47: Conditional fallback to bump action.
This follows the established pattern of returning any validation errors in tandem with aBumpIdentityDataContractNonceActionif validation fails.Also applies to: 48-64
89-101: Owner reassignment and final purchase transition data.
Removing thePRICE, transferring ownership fromoriginal_owner_idtopurchaser_id, updating revision and timestamps, and returning the default fee is correct for a purchase flow.packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/v0/transformer.rs (4)
6-6: New imports look good.These new imports for fee handling (
FeeResult), user fee increases (UserFeeIncrease), and batching actions (BatchedTransitionAction,DocumentTransitionAction,BumpIdentityDataContractNonceAction) appear consistent with the expanded functionality.Also applies to: 8-8, 12-12, 13-13, 16-16, 17-17
34-40: Return type refactor aligns with fee + validation flow.Switching to
Result<(ConsensusValidationResult<BatchedTransitionAction>, FeeResult), Error>adds clarity by pairing the validation result with the corresponding fee outcome. This setup follows the other transitions' patterns well.
55-75: Graceful fallback to nonce bump action on invalid base transition.When the base transition is invalid, returning a
BumpIdentityDataContractNonceActionwithConsensusValidationResultis a clear approach to preserve error details. This modular design is good for maintaining distinct fallback routes.
24-24:❓ Verification inconclusive
Confirm usage of new parameters.
The extra parameters
owner_idanduser_fee_increasesuit the new logic. Ensure all call sites that invoketry_from_borrowed_document_replace_transitionproperly pass these new arguments in alignment with intended ownership and fee adjustments.Run this script to find relevant call sites in the codebase:
Also applies to: 32-32
🏁 Script executed:
#!/bin/bash # Searching for all calls to try_from_borrowed_document_replace_transition rg "try_from_borrowed_document_replace_transition"Length of output: 901
Ensure all call sites pass the updated parameters correctly.
The new parameters (
owner_idat line 24 anduser_fee_increaseat line 32) have been added to support the revised ownership and fee logic. I verified that the methodtry_from_borrowed_document_replace_transitionis defined and called in multiple places (for instance, in thepackages/rs-drivetransformer file and in the ABCI module atpackages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs). Please double-check that every invocation of this method supplies the new parameters in the proper order and with the intended values.
- Verify that call sites in
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_replace_transition_action/v0/transformer.rscorrectly pass bothowner_idanduser_fee_increase.- Confirm that the invocation in
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rshas been updated accordingly.
...atch/batched_transition/document_transition/document_create_transition_action/transformer.rs
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
packages/rs-sdk/src/platform/transition/update_price_of_document.rs (1)
15-115: 💡 Verification agent🧩 Analysis chain
Ensure tests cover token payment scenarios.
As this adds functionality for token payments when updating document prices, verify that there are corresponding tests covering:
- Regular update price without token payment
- Update price with token payment information
- Edge cases like invalid token payment parameters
🏁 Script executed:
#!/bin/bash # Check if there are tests that cover the token payment functionality for # document price updates echo "Searching for tests related to update_price_of_document with token payments..." rg -A 10 "update_price_of_document.*token_payment" --type rust --glob "**/*test*.rs"Length of output: 253
Action Required: Add Token Payment Test Coverage
It appears that no tests were found covering token payment scenarios for the document price update functionality. Please ensure that tests are added to cover all cases, including:
- Regular update price calls without token payment.
- Updates using valid token payment information.
- Edge cases with invalid token payment parameters.
🧹 Nitpick comments (4)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs (1)
13-14: Function documentation needs improvement.The current comment "from borrowed" is insufficient. Consider updating it to describe the function's purpose, parameters, and return values, especially given the significant changes to the signature and behavior.
- /// from borrowed + /// Creates a DocumentDeleteTransitionAction from a borrowed DocumentDeleteTransition + /// with owner identification and fee handling. + /// + /// # Parameters + /// * `value` - The document delete transition to transform + /// * `owner_id` - The identifier of the document owner + /// * `user_fee_increase` - Fee increase configured by the user + /// * `get_data_contract` - Function to retrieve the data contract + /// + /// # Returns + /// A result containing validation results and fee information, or an errorpackages/rs-sdk/src/platform/transition/transfer_document.rs (1)
22-23: Method signature updated with appropriate Clippy suppression.The new
token_payment_infoparameter is properly added to the trait method. The Clippy suppression for too many arguments is appropriate since this interface needs to maintain all parameters.Consider adding documentation for the new parameter to clarify its purpose and usage.
Add documentation for the new parameter:
/// Transfers a document on platform /// Setting settings to `None` sets default connection behavior + /// + /// # Parameters + /// * `token_payment_info` - Optional token payment details for the document transfer #[allow(clippy::too_many_arguments)] async fn transfer_document_to_identity(Also applies to: 29-30
packages/rs-sdk/src/platform/transition/update_price_of_document.rs (2)
22-23: Update method documentation to reflect the new parameter.The method documentation should be updated to describe the purpose and behavior of the new
token_payment_infoparameter, especially explaining what happens whenNoneis provided./// Updates the price of a document on platform /// Setting settings to `None` sets default connection behavior +/// When `token_payment_info` is provided, it specifies token payment details for this action. +/// When `None` is provided, no token payment will be associated with this action. #[allow(clippy::too_many_arguments)]Also applies to: 29-30
35-36: Update wait_for_response method documentation.Similar to the base method, this documentation should also be updated to describe the new parameter.
/// Updates the price of a document on platform and waits for the response +/// When `token_payment_info` is provided, it specifies token payment details for this action. +/// When `None` is provided, no token payment will be associated with this action. #[allow(clippy::too_many_arguments)]Also applies to: 42-43
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs(13 hunks)packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs(1 hunks)packages/rs-sdk/src/platform/transition/transfer_document.rs(5 hunks)packages/rs-sdk/src/platform/transition/update_price_of_document.rs(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rs
⏰ Context from checks skipped due to timeout of 90000ms (19)
- GitHub Check: Rust packages (rs-dapi-client) / Detect immutable structure changes
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Rust packages (dapi-grpc) / Unused dependencies
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (drive-abci) / Unused dependencies
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive) / Formatting
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dash-sdk) / Linting
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (14)
packages/rs-drive/src/state_transition_action/batch/batched_transition/document_transition/document_delete_transition_action/transformer.rs (5)
3-4: Added imports for fee handling and validation results.These imports support the new functionality for handling fees and validation results during document deletion, aligning with the PR's goal of enhancing token payment processing.
8-9: Error type change and BatchedTransitionAction import.The change from
ProtocolErrortoErrorand the addition ofBatchedTransitionActionsupport the new return type structure. This change is necessary for the fee handling and validation functionality.
14-25: Method signature updated to support fee handling and validation.The method has been properly renamed to reflect its purpose (delete instead of create) and now includes parameters for owner identification and fee management. The return type has been updated to include both validation results and fee information, which aligns with the PR objective of enhancing the payment process for documents.
27-27: Implementation updated to match new signature.The function call has been properly updated to pass the new parameters to the underlying implementation. This ensures consistency in the token payment processing chain.
1-30:✅ Verification successful
Verify impact of breaking changes across the codebase.
This method has undergone significant changes in both signature and return type, which constitutes a breaking change as noted in the PR objectives. Ensure that all callers of this method have been updated accordingly.
🏁 Script executed:
#!/bin/bash # Search for any calls to the old method name that might need updating echo "Searching for potential places that need updating..." rg "try_from_document_borrowed_create_transition_with_contract_lookup" --type rust # Search for any calls to the new method name to ensure proper parameter passing echo "Checking current implementations..." rg "try_from_document_borrowed_delete_transition_with_contract_lookup" --type rustLength of output: 2704
Breaking Change Verified: DocumentDeleteTransitionAction Update Is Consistent Across the Codebase
- Confirmed that all calls to the delete transition method now correctly use the new signature of
try_from_document_borrowed_delete_transition_with_contract_lookup.- The updated call in
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/transformer/v0/mod.rsshows proper parameter passing, and no residual references to an outdated delete signature were found.- Note that existing calls for document creation (using
try_from_document_borrowed_create_transition_with_contract_lookup) remain unaffected.packages/rs-sdk/src/platform/transition/transfer_document.rs (5)
14-14: Appropriate import added for the new feature.The import of
TokenPaymentInfois correctly added to support the new token payment functionality in document transfers.
35-36: Method signature with wait updated correctly.The token payment parameter is consistently added to the wait-for-response variant of the method with appropriate Clippy suppression.
Also applies to: 42-43
56-57: Implementation correctly passes token payment information.The implementation properly handles the new parameter and passes it to the batch transition creation function where it will be used.
Also applies to: 78-79
105-106: Token payment parameter is consistently forwarded in method chain.The implementation of the wait-for-response method correctly forwards the token payment information to the underlying method.
Also applies to: 115-116
22-84:❓ Verification inconclusive
Verify error handling for invalid token payment information.
While the implementation passes the token payment information correctly, there's no explicit error handling visible for cases where the token payment information might be invalid for the specific document or document type.
🏁 Script executed:
#!/bin/bash # Check how invalid token payment is validated in the batch transition implementation rg -A 10 "new_document_transfer_transition_from_document" --type=rustLength of output: 20247
Clarify Token Payment Info Validation and Error Propagation
The current implementation directly forwards the token payment info to the underlying
BatchTransition::new_document_transfer_transition_from_documentfunction without any pre-validation in thetransfer_document_to_identitymethod. Please ensure that:
- The underlying
BatchTransitionimplementation properly verifies token payment information and returns an error when it is invalid.- If the design relies solely on this delegation, add documentation or explicit tests to confirm that invalid token payment info cases are correctly handled.
packages/rs-sdk/src/platform/transition/update_price_of_document.rs (4)
15-15: LGTM: New import for TokenPaymentInfo.The import is correctly added to support the new token payment functionality.
56-57: LGTM: Properly added token_payment_info parameter to method implementation.The implementation correctly uses the new parameter and passes it to the
BatchTransitioncreation method.Also applies to: 78-79
97-110: LGTM: Properly updated method call to include token_payment_info.The call to
update_price_of_documentfromupdate_price_of_document_and_wait_for_responsecorrectly passes the new parameter, maintaining consistency between the two methods.
22-84:✅ Verification successful
Verify token payment parameter handling in batch transition method.
Need to ensure that the
new_document_update_price_transition_from_documentmethod properly handles the token payment information.
🏁 Script executed:
#!/bin/bash # Find the implementation of new_document_update_price_transition_from_document to verify # if it correctly handles the token_payment_info parameter echo "Searching for the implementation of new_document_update_price_transition_from_document..." rg -A 5 "new_document_update_price_transition_from_document" --type rustLength of output: 16737
🏁 Script executed:
#!/bin/bash # Search for references to token_payment_info in the dpp state transition methods to verify parameter handling. rg "token_payment_info" --type rust packages/rs-dppLength of output: 27964
Token Payment Parameter Handling Verified
After reviewing the implementation details, the
token_payment_infoparameter is correctly propagated from the SDK method into the underlying DPP batch transition methods (both v0 and v1). The references in the DPP code (e.g., in the files underpackages/rs-dpp/src/state_transition/...) confirm that the optional token payment parameter is consistently passed and handled without issues.No changes are necessary here.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/rs-dpp/src/document/extended_document/v0/mod.rs (2)
127-135: Ensure serialization/deserialization is fully tested.
Adding a new optionaltoken_payment_infofield is straightforward. However, consider verifying how it behaves when None vs. Some in both JSON and platform value contexts.Would you like me to help draft some tests that confirm correct handling of this field?
370-377: Repeated logic for extractingtoken_payment_info.
You are performing the same optional extraction sequence as infrom_trusted_platform_value. To reduce duplication, consider refactoring this into a helper function.+fn parse_token_payment_info( + properties: &mut BTreeMap<String, Value> +) -> Result<Option<TokenPaymentInfo>, ProtocolError> { + properties + .remove_optional_map_as_btree_map_keep_values_as_platform_value( + property_names::TOKEN_PAYMENT_INFO, + ) + .ok() + .flatten() + .map(|map| map.try_into()) + .transpose() +}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/rs-dpp/src/document/extended_document/v0/mod.rs(14 hunks)packages/rs-dpp/src/tokens/token_payment_info/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/rs-dpp/src/tokens/token_payment_info/mod.rs
⏰ Context from checks skipped due to timeout of 90000ms (18)
- GitHub Check: Rust packages (wasm-dpp) / Unused dependencies
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (wasm-dpp) / Formatting
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dash-sdk) / Linting
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Unused dependencies
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- 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 JS packages / Build JS
🔇 Additional comments (8)
packages/rs-dpp/src/document/extended_document/v0/mod.rs (8)
14-14: Imports look correct.
This import ofDocumentV0Gettersis aligned with existing usage patterns. No concerns here.
30-33: Conditional compilation block looks appropriate.
These lines correctly ensure that serialization logic is enabled only when bothdocument-serde-conversionanddata-contract-serde-conversionfeatures are active.
47-47: New import forTokenPaymentInfois valid.
No issues with bringing inTokenPaymentInfoas it is directly referenced below.
235-235: Constructor updates look good.
Accepting and assigning thetoken_payment_infoparameter is consistent with the new field. Confirm its usage in other parts of the codebase is tested.Also applies to: 244-244
311-318: Optional token payment info extraction is correct.
The use ofremove_optional_map_as_btree_map_keep_values_as_platform_valueflowing intotry_into()is a clean approach.
436-442: JSON insertion logic is coherent.
Storing the serialized token payment info when present is consistent with the rest of the JSON-conversion pattern.
457-462: Insertingtoken_payment_infointo map.
This insertion aligns with code in other methods. Good consistency in handling the optional field.
472-472: Destructuring and insertion remain consistent.
Destructuringtoken_payment_infoand conditionally inserting it matches the same design pattern used above. No immediate issues.Also applies to: 486-491
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (2)
14-14: Remove unused imports.The static analysis correctly identified that
DeserializeandSerializeare imported but not used in this file. Consider removing these unused imports to keep the code clean.- use serde::{Deserialize, Serialize}; + use serde;Or if you plan to use these traits in the future, add a comment explaining why they're included.
🧰 Tools
🪛 GitHub Check: Rust packages (drive-abci) / Linting
[warning] 14-14: unused imports:
DeserializeandSerialize
warning: unused imports:DeserializeandSerialize
--> packages/rs-dpp/src/tokens/gas_fees_paid_by.rs:14:13
|
14 | use serde::{Deserialize, Serialize};
| ^^^^^^^^^^^ ^^^^^^^^^
|
= note:#[warn(unused_imports)]on by default🪛 GitHub Check: Rust packages (drive) / Linting
[warning] 14-14: unused imports:
DeserializeandSerialize
warning: unused imports:DeserializeandSerialize
--> packages/rs-dpp/src/tokens/gas_fees_paid_by.rs:14:13
|
14 | use serde::{Deserialize, Serialize};
| ^^^^^^^^^^^ ^^^^^^^^^
|
= note:#[warn(unused_imports)]on by default
24-33: Add documentation for the enum.While the individual variants have good documentation, consider adding a doc comment for the enum itself to explain its overall purpose and usage in the token payment context.
+/// Represents who is responsible for paying gas fees in token-related operations. +/// This enum is used in token payment information to specify the payer of gas fees. pub enum GasFeesPaidBy { /// The user pays the gas fees #[default] DocumentOwner = 0, /// The contract owner pays the gas fees ContractOwner = 1, /// The user is stating his willingness to pay the gas fee if the Contract owner's balance is /// insufficient. PreferContractOwner = 2, }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs(1 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (6)
packages/rs-dpp/src/errors/consensus/basic/basic_error.rs (1)
from(521-523)packages/rs-dpp/src/errors/consensus/state/token/identity_trying_to_pay_with_wrong_token_error.rs (2)
from(96-98)new(23-39)packages/rs-dpp/src/errors/consensus/basic/data_contract/token_payment_by_burning_only_allowed_on_internal_token_error.rs (2)
from(73-75)new(23-33)packages/rs-dpp/src/errors/protocol_error.rs (4)
from(296-298)from(302-304)from(308-310)from(314-316)packages/rs-dpp/src/tokens/token_payment_info/v0/mod.rs (1)
try_from(114-136)packages/rs-dpp/src/errors/consensus/basic/data_contract/unknown_gas_fees_paid_by_error.rs (1)
new(26-31)
🪛 GitHub Check: Rust packages (drive-abci) / Linting
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs
[warning] 14-14: unused imports: Deserialize and Serialize
warning: unused imports: Deserialize and Serialize
--> packages/rs-dpp/src/tokens/gas_fees_paid_by.rs:14:13
|
14 | use serde::{Deserialize, Serialize};
| ^^^^^^^^^^^ ^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default
🪛 GitHub Check: Rust packages (drive) / Linting
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs
[warning] 14-14: unused imports: Deserialize and Serialize
warning: unused imports: Deserialize and Serialize
--> packages/rs-dpp/src/tokens/gas_fees_paid_by.rs:14:13
|
14 | use serde::{Deserialize, Serialize};
| ^^^^^^^^^^^ ^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default
⏰ Context from checks skipped due to timeout of 90000ms (19)
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (dpp) / Unused dependencies
- GitHub Check: Rust packages (dpp) / Detect immutable structure changes
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Rust packages (dash-sdk) / Unused dependencies
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Linting
- GitHub Check: Rust packages (rs-dapi-client) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Formatting
- GitHub Check: Rust packages (rs-dapi-client) / Linting
- GitHub Check: Rust packages (dapi-grpc) / Linting
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
🔇 Additional comments (3)
packages/rs-dpp/src/tokens/gas_fees_paid_by.rs (3)
45-61: Great error handling implementation.This implementation provides comprehensive error handling for invalid conversion attempts, with clear error messages and context. The use of the
UnknownGasFeesPaidByErrorwith allowed values helps developers understand what went wrong.
63-78: Well-structured conversion from u64.The implementation properly handles the conversion from u64 to u8 first, with appropriate error handling, and then delegates to the u8 implementation. This approach avoids code duplication and maintains consistency in error reporting.
1-78: Good implementation of the GasFeesPaidBy enum.This new enum aligns well with the PR objectives of enhancing the token payment information feature. The implementation is thorough with appropriate error handling, default values, and conversion methods. The enum clearly defines who is responsible for paying gas fees in various scenarios, which is a critical part of the token payment system.
🧰 Tools
🪛 GitHub Check: Rust packages (drive-abci) / Linting
[warning] 14-14: unused imports:
DeserializeandSerialize
warning: unused imports:DeserializeandSerialize
--> packages/rs-dpp/src/tokens/gas_fees_paid_by.rs:14:13
|
14 | use serde::{Deserialize, Serialize};
| ^^^^^^^^^^^ ^^^^^^^^^
|
= note:#[warn(unused_imports)]on by default🪛 GitHub Check: Rust packages (drive) / Linting
[warning] 14-14: unused imports:
DeserializeandSerialize
warning: unused imports:DeserializeandSerialize
--> packages/rs-dpp/src/tokens/gas_fees_paid_by.rs:14:13
|
14 | use serde::{Deserialize, Serialize};
| ^^^^^^^^^^^ ^^^^^^^^^
|
= note:#[warn(unused_imports)]on by default
packages/rs-dpp/schema/meta_schemas/document/v0/document-meta.json
Outdated
Show resolved
Hide resolved
|
Good job! |
Issue being fixed or feature implemented
When a user paid for an NFT/document the price could have changed, this introduces a token payment info where the user tells the contract what he's willing to pay. Often this will be the price he sees.
Also when purchasing with an external token you may only transfer to the contract owner (for now).
When purchasing with an internal to the contract token you may transfer to the contract owner and also burn the token.
What was done?
A lot of the above features.
We also added a lot more tests and better validation.
We added a field for who pays the fees of the state transition if someone does a document action that requires a token payment, however this has not yet been implemented. We will implement it in next PR.
We added the ability for the purchaser of the NFT to say in advance what token price they are okay with.
How Has This Been Tested?
A lot of tests were added.
Breaking Changes
Breaking vis a vis current 2.0
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
New Features
Refactor & Error Handling
Tests