-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem: sender check for MsgStoreBlockList is not in CheckTx #1613
Conversation
WalkthroughThe changes introduced in this pull request include updates to the Changes
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1613 +/- ##
==========================================
+ Coverage 36.00% 36.31% +0.31%
==========================================
Files 123 123
Lines 9791 9715 -76
==========================================
+ Hits 3525 3528 +3
+ Misses 5851 5773 -78
+ Partials 415 414 -1
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (5)
x/cronos/types/messages_test.go (1)
66-69
: Suggestion: Improve error handling in key parsing.The current implementation uses
log.Fatalf
which will terminate the program if the key parsing fails. In a test context, it might be more appropriate to uset.Fatalf
to fail the test instead.Consider replacing the error handling with:
- if err != nil { - log.Fatalf("Failed to parse public key %q: %v", publicKey, err) - } + require.NoError(t, err, fmt.Sprintf("Failed to parse public key %q", publicKey))This change will provide more consistent error reporting within the test framework.
x/cronos/types/messages.go (3)
338-339
: LGTM. Consider adding a comment explaining the chosen value.The introduction of
MaximumBlobLength
is a good practice to limit the size of theBlob
field. However, it would be beneficial to add a comment explaining why 20480 (20 KB) was chosen as the maximum length. This helps future maintainers understand the reasoning behind this limit.Consider adding a comment like:
// MaximumBlobLength defines the maximum allowed length for the Blob field. // It is set to 20 KB to [explain the reason for this specific limit]. const MaximumBlobLength = 20480
347-350
: LGTM. Consider a minor optimization.The new validation logic for the blob length is correct and well-implemented. It properly enforces the
MaximumBlobLength
limit and provides a clear error message.For a minor optimization, consider storing the length in a variable to avoid calling
len(msg.Blob)
twice:blobLength := len(msg.Blob) if blobLength > MaximumBlobLength { return errors.Wrapf(sdkerrors.ErrInvalidRequest, "block length %d must not exceed %d", blobLength, MaximumBlobLength) }This change would slightly improve readability and prevent redundant length calculations.
355-356
: LGTM. Consider clarifying the comment slightly.The added comment provides valuable context for the use of
errDummyIdentity
in theDecrypt
operation. It's helpful in explaining the rationale behind this error handling approach.To improve clarity, consider slightly rewording the comment:
// Use errDummyIdentity for early return to skip heavy decryption operation. // This approach is based on the implementation in: // https://github.com/FiloSottile/age/blob/v1.1.1/age.go#L197This rewording makes the purpose of using
errDummyIdentity
more explicit and separates the explanation from the reference link.CHANGELOG.md (1)
Line range hint
13-29
: Consider adding release date for v1.0.7For better version tracking and historical reference, it would be helpful to include the release date for v1.0.7 in the changelog.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- CHANGELOG.md (1 hunks)
- x/cronos/types/messages.go (1 hunks)
- x/cronos/types/messages_test.go (2 hunks)
🧰 Additional context used
🪛 Gitleaks
x/cronos/types/messages_test.go
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (5)
x/cronos/types/messages_test.go (2)
17-17
: LGTM: Bech32 prefix configuration added.The addition of
cmdcfg.SetBech32Prefixes(sdk.GetConfig())
ensures consistent address formatting across tests, which is a good practice for maintaining test reliability.
62-135
: LGTM: Comprehensive test cases for MsgStoreBlockList validation.The new test function
TestValidateMsgStoreBlockList
effectively addresses the PR objective of validating maximum length for blob messages. The test cases cover various scenarios, including valid input, exceeding maximum blob length, invalid sender address, and decryption errors. The use of age encryption adds a layer of security to the blob storage mechanism.🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
x/cronos/types/messages.go (1)
338-356
: Overall, the changes look good and address the PR objectives.The modifications to
x/cronos/types/messages.go
successfully implement max length validation for blob messages in theMsgStoreBlockList
struct. The changes are well-implemented, consistent with the existing code style, and improve the robustness of the system.Key improvements:
- Introduction of
MaximumBlobLength
constant.- Implementation of blob length validation in
ValidateBasic
.- Addition of a helpful comment explaining the
errDummyIdentity
usage.The suggestions provided in the review are minor and aimed at further improving code clarity and efficiency. Overall, these changes effectively address the issue of "no max length validation for blob msg" as described in the PR objectives.
CHANGELOG.md (2)
11-11
: LGTM: New feature added to changelogThe addition of max length validation for blob messages is correctly documented in the changelog. This aligns with the PR objectives mentioned earlier.
Line range hint
1-1023
: LGTM: Well-structured and informative changelogThe changelog is well-organized, providing a clear history of changes across multiple versions. It consistently categorizes changes (e.g., "State Machine Breaking", "Bug Fixes", "Features", "Improvements") and often includes links to relevant GitHub issues or pull requests. This structure makes it easy for users and developers to understand the project's evolution.
5935f05
to
cc638bf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- CHANGELOG.md (1 hunks)
- x/cronos/types/messages.go (1 hunks)
- x/cronos/types/messages_test.go (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- CHANGELOG.md
- x/cronos/types/messages.go
🧰 Additional context used
🪛 Gitleaks
x/cronos/types/messages_test.go
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (5)
x/cronos/types/messages_test.go (5)
4-11
: LGTM: New imports added for the test function.The new imports are correctly added to support the functionality of the new test function
TestValidateMsgStoreBlockList
.
17-17
: LGTM: Proper test environment setup.The addition of
cmdcfg.SetBech32Prefixes(sdk.GetConfig())
ensures that the Bech32 prefixes are correctly set for the test environment, which is a good practice for maintaining consistent test conditions.
62-135
: LGTM: Comprehensive test coverage forMsgStoreBlockList
validation.The new test function
TestValidateMsgStoreBlockList
provides good coverage of various scenarios:
- Valid message
- Blob exceeding maximum length
- Invalid sender address
- Decryption error
The test structure is clear and follows good practices. The use of the
age
package for encryption testing is appropriate.🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
115-124
: LGTM: Well-implemented encryption logic for test cases.The encryption logic is correctly implemented using the
age
package. It's applied conditionally based on thenoEncrypt
flag, which allows for testing both encrypted and unencrypted scenarios. The use of a buffer to store encrypted data is efficient, and error handling is properly done withrequire.NoError
.
126-132
: LGTM: Thorough validation and error checking.The validation and error checking logic is well-implemented. It correctly calls
ValidateBasic()
on the message and checks for expected errors, including their specific content. The differentiation between expected errors and unexpected successes ensures that the test cases are properly validated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
x/cronos/types/messages.go (2)
203-215
: Approve changes toValidateBasic
method with a minor suggestion.The modifications to the
ValidateBasic
method ofMsgStoreBlockList
are well-implemented:
- The length check using
MaximumBlobLength
is correctly added to enforce the blob size limit.- The added comment explains the purpose of the early return with
errDummyIdentity
, improving code readability.These changes enhance the robustness of the validation process for blob messages.
Consider extracting the error message for the length check into a constant for better maintainability:
+const errMsgBlobTooLarge = "block length %d must not exceed %d" func (msg *MsgStoreBlockList) ValidateBasic() error { length := len(msg.Blob) if length > MaximumBlobLength { - return errors.Wrapf(sdkerrors.ErrInvalidRequest, "block length %d must not exceed %d", length, MaximumBlobLength) + return errors.Wrapf(sdkerrors.ErrInvalidRequest, errMsgBlobTooLarge, length, MaximumBlobLength) } // ... rest of the method }This minor change would make it easier to update the error message in the future if needed.
Line range hint
1-215
: Summary of changes and their impactThis PR successfully implements the max length validation for blob messages as stated in the objectives. The changes include:
- Introduction of
MaximumBlobLength
constant (20KB limit).- Implementation of length validation in
MsgStoreBlockList.ValidateBasic()
.Additionally, several significant changes were made that were not explicitly mentioned in the PR objectives:
- Removal of multiple message type constants (
TypeMsgConvertVouchers
,TypeMsgTransferTokens
,TypeMsgTurnBridge
,TypeMsgUpdatePermissions
,TypeMsgStoreBlockList
).- Removal of associated methods for these message types.
These removals represent a substantial change to the module's API and functionality. Please ensure that:
- These changes are thoroughly documented in the CHANGELOG.
- Any dependent modules or external systems are updated accordingly.
- The impact of these removals on the overall system architecture is well understood and communicated to the team.
Consider creating a migration guide or deprecation notice for users of the removed message types, if applicable. This will help ensure a smooth transition for any systems relying on the removed functionality.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- CHANGELOG.md (1 hunks)
- x/cronos/types/messages.go (2 hunks)
- x/e2ee/types/msg.go (0 hunks)
💤 Files with no reviewable changes (1)
- x/e2ee/types/msg.go
🚧 Files skipped from review as they are similar to previous changes (1)
- CHANGELOG.md
🧰 Additional context used
🔇 Additional comments (2)
x/cronos/types/messages.go (2)
194-195
: Approve the introduction ofMaximumBlobLength
constant.The addition of
MaximumBlobLength
constant with a value of 20480 (20KB) is a good practice to enforce a size limit on blob messages. This helps prevent potential issues related to processing or storing excessively large blobs.Regarding the past discussion about whether 20KB is sufficient:
- The chosen limit seems reasonable for most use cases.
- As mentioned in the previous comments, there's already a max transaction size limit in place, which provides an additional safeguard.
However, to ensure this limit is appropriate:
- Verify that 20KB is sufficient for all valid use cases of blob messages in your system.
- Consider making this value configurable (e.g., through governance or a module parameter) to allow for future adjustments if needed.
To help determine if the 20KB limit is appropriate, you can analyze the current blob sizes in your system:
#!/bin/bash # Analyze blob sizes in the codebase rg --type go -A 10 "MsgStoreBlockList" | rg "Blob:" | awk '{print length($2)}' | sort -n | uniq -cThis command will show the distribution of blob sizes, helping you confirm if the 20KB limit is suitable for your use case.
15-15
: Verify the impact of removed message type constants.The removal of several message type constants (
TypeMsgConvertVouchers
,TypeMsgTransferTokens
,TypeMsgTurnBridge
,TypeMsgUpdatePermissions
,TypeMsgStoreBlockList
) suggests significant changes in the module's functionality. Please ensure that:
- These message types are no longer used anywhere in the codebase.
- Any external systems or modules depending on these message types have been updated accordingly.
- The removal of these constants is documented in the CHANGELOG.
To confirm that the removed constants are not used elsewhere in the codebase, run the following command:
If this command returns any results, those occurrences need to be addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (5)
x/cronos/types/messages.go (3)
205-210
: Approve changes with suggestion for additional validationThe added validation logic improves the security of the
MsgStoreBlockList
by ensuring the blob is properly encrypted. The comment provides clarity on the purpose of usingerrDummyIdentity
.However, consider adding a maximum length check for the blob to prevent potential performance issues with extremely large blobs.
Consider adding a maximum length check for the blob before attempting decryption. For example:
func (msg *MsgStoreBlockList) ValidateBasic() error { _, err := sdk.AccAddressFromBech32(msg.From) if err != nil { return errors.Wrapf(sdkerrors.ErrInvalidAddress, "invalid sender address (%s)", err) } + if len(msg.Blob) > MaxBlobSize { + return errors.Wrapf(sdkerrors.ErrInvalidRequest, "blob size exceeds maximum allowed (%d > %d)", len(msg.Blob), MaxBlobSize) + } // skip heavy operation in Decrypt by early return with errDummyIdentity in // https://github.com/FiloSottile/age/blob/v1.1.1/age.go#L197 _, err = age.Decrypt(bytes.NewBuffer(msg.Blob), new(dummyIdentity)) if err != nil && err != errDummyIdentity { return err } return nil }Make sure to define
MaxBlobSize
as a constant at the package level.
Line range hint
1-210
: Summary of changes and recommendation for thorough testingThis file has undergone significant changes, including the removal of several message types and the addition of new validation logic. While the visible changes appear appropriate, the extent of the removals suggests a larger refactoring effort.
Given the scope of these changes:
- Ensure that all affected parts of the codebase have been updated to reflect these changes.
- Update any relevant documentation to reflect the removed message types and new validation logic.
- Conduct thorough testing, including integration tests, to verify that these changes don't introduce any regressions or unexpected behavior.
- Consider updating the CHANGELOG.md to reflect these significant changes.
Consider creating a migration guide if these changes affect external integrations or APIs.
Issues Found with Removed Message Types and Methods
The removal of several message type constants and their associated methods has led to multiple references remaining in the codebase. This will likely cause compilation errors and disrupt existing functionality.
Affected Files:
x/cronos/types/codec.go
x/cronos/types/messages_test.go
x/cronos/types/messages.go
x/cronos/types/tx.pb.go
x/cronos/keeper/msg_server.go
x/cronos/handler_test.go
x/cronos/client/cli/tx.go
app/block_address.go
Please address these references to ensure the codebase remains consistent and functional.
🔗 Analysis chain
Line range hint
1-210
: Verify impact of removed message types and methodsThe AI-generated summary indicates that several message type constants and their associated methods have been removed from this file. While these removals are not directly visible in the provided code, it's crucial to ensure that they don't negatively impact the existing functionality or cause issues in other parts of the codebase.
Please run the following script to check for any remaining references to the removed message types:
This script will help identify any remaining references to the removed message types and structs in the codebase. If any references are found, they may need to be updated or removed to maintain consistency with these changes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for references to removed message types in the codebase # List of removed message types removed_types=( "TypeMsgConvertVouchers" "TypeMsgTransferTokens" "TypeMsgUpdateParams" "TypeMsgTurnBridge" "TypeMsgUpdatePermissions" "TypeMsgStoreBlockList" ) # Search for references to removed types for type in "${removed_types[@]}"; do echo "Searching for references to $type:" rg --type go "$type" echo done # Search for uses of removed message structs echo "Searching for uses of removed message structs:" rg --type go "MsgConvertVouchers|MsgTransferTokens|MsgTurnBridge|MsgUpdatePermissions|MsgStoreBlockList"Length of output: 32680
CHANGELOG.md (2)
Line range hint
27-36
: Multiple improvements and bug fixes in dependencies.This update includes several important changes:
- Upgrade to Cosmos SDK v0.47.5 and IBC-Go v7.2.0
- Support for stateful precompiled contracts for relayer and ICA
- Removal of the Gravity module
- Increase in max block gas limit
- Support for IBC callback
These changes represent significant improvements in functionality and performance. However, they also introduce breaking changes that may require updates to dependent applications.
Consider providing a migration guide or upgrade instructions for users and developers to ensure a smooth transition to this new version.
Line range hint
1-1185
: Overall assessment of v1.1.0-rc0 changesThe changes introduced in v1.1.0-rc0 represent a significant update to the Cronos blockchain. Key improvements include:
- Enhanced security with admin sender checks for MsgStoreBlockList
- Critical bug fixes for genesis migration, state synchronization, and data integrity
- Major dependency upgrades (Cosmos SDK, IBC-Go)
- Introduction of stateful precompiled contracts for relayer and ICA
- Removal of the Gravity module
- Increased max block gas limit
- Support for IBC callback
These changes should improve the overall performance, security, and functionality of the Cronos blockchain. However, the breaking changes, particularly the removal of the Gravity module and the introduction of new features, may require significant updates to dependent applications and tools.
- Provide comprehensive upgrade instructions and migration guides for node operators and developers.
- Consider a phased rollout or testnet period to ensure smooth transition and identify any potential issues before mainnet deployment.
- Communicate clearly with the community about the implications of these changes, especially the removal of the Gravity module and how it might affect existing integrations.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
- CHANGELOG.md (1 hunks)
- app/app.go (1 hunks)
- app/block_address.go (2 hunks)
- x/cronos/types/messages.go (2 hunks)
- x/cronos/types/messages_test.go (2 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
app/block_address.go
[warning] 42-46: app/block_address.go#L42-L46
Added lines #L42 - L46 were not covered by tests
🪛 Gitleaks
x/cronos/types/messages_test.go
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (13)
x/cronos/types/messages_test.go (4)
17-17
: LGTM: Improved test setup with Bech32 prefixes.The addition of
cmdcfg.SetBech32Prefixes(sdk.GetConfig())
enhances the test environment by configuring the correct Bech32 address prefixes. This change ensures that the test conditions more accurately reflect the real blockchain environment.
65-65
: Consider moving the hardcoded public key to a test constant.While the current implementation works for testing purposes, it's generally a good practice to avoid hardcoding sensitive information directly in the code. Consider moving this public key to a separate test constant or configuration file to improve maintainability and reduce the risk of accidentally exposing sensitive information.
🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
62-125
: LGTM: Well-structured test function with good coverage.The
TestValidateMsgStoreBlockList
function is well-implemented and covers important test cases:
- Valid message scenario
- Invalid sender address scenario
- Decryption error scenario
The use of the
age
package for encryption testing is appropriate, and the test structure allows for easy addition of more test cases if needed in the future.🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Line range hint
1-125
: Summary: Improved test coverage and environment setup.The changes in this file enhance the test suite in two ways:
- The existing
TestValidateMsgUpdateTokenMapping
function now includes proper Bech32 prefix setup, ensuring a more accurate test environment.- The new
TestValidateMsgStoreBlockList
function provides comprehensive testing for theMsgStoreBlockList
message type, including encryption scenarios.These improvements contribute to a more robust and reliable test suite for the Cronos blockchain types. The only minor suggestion is to consider moving the hardcoded public key to a constant for better maintainability.
🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
x/cronos/types/messages.go (1)
15-15
: LGTM: New constant added for MsgUpdateTokenMappingThe addition of
TypeMsgUpdateTokenMapping
constant is consistent with the existing code structure and naming conventions.CHANGELOG.md (4)
18-18
: New feature: Check admin sender for MsgStoreBlockList in check tx.This change adds a security check for the admin sender when processing MsgStoreBlockList transactions. This is an important security improvement that helps prevent unauthorized modifications to the block list.
Line range hint
22-23
: Bug fix: Fix genesis migrate for feeibc, evm, feemarket and gravity.This fix addresses migration issues for several modules during genesis. It's crucial for ensuring proper initialization of the chain state after upgrades.
Line range hint
24-24
: Bug fix: Fix lock issues when state-sync with memiavl.Resolving lock issues during state synchronization is important for maintaining data consistency and preventing potential deadlocks.
Line range hint
25-25
: Bug fix: Fix memiavl's unsafe retain of the root hashes.Addressing unsafe retention of root hashes in memiavl is crucial for maintaining data integrity and preventing potential security vulnerabilities.
app/app.go (1)
1109-1109
: LGTM. Verify impact on transaction processing.The addition of
app.CronosKeeper.GetParams
to theNewBlockAddressesDecorator
initialization looks good. This change allows the decorator to access dynamic parameters from the Cronos module, which could enhance the flexibility of blocked address handling.To ensure this change doesn't introduce unexpected behavior, please run the following verification:
✅ Verification successful
Verified:
NewBlockAddressesDecorator
correctly integratesGetParams
, ensuring blocked addresses are properly handled in transaction processing.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any changes in transaction processing related to blocked addresses # Test: Search for usage of GetParams in BlockAddressesDecorator rg --type go 'func.*BlockAddressesDecorator' -A 10 | grep 'GetParams' # Test: Look for any changes in transaction processing logic related to blocked addresses rg --type go 'func.*checkBlockedAddress' -A 20Length of output: 118
Script:
#!/bin/bash # Description: Search for all usages of GetParams in the codebase rg --type go 'GetParams' # Description: Retrieve all instances where NewBlockAddressesDecorator is initialized rg --type go 'NewBlockAddressesDecorator' -A 5 # Description: Search for any changes in transaction processing functions related to blocked addresses rg --type go 'checkBlockedAddress' -A 20Length of output: 2704
Script:
#!/bin/bash # Description: Search for functions related to blocked address validation with varied naming rg --type go 'func.*(validate|is|check).*BlockedAddress' -A 20 # Description: Retrieve all usages of BlockAddressesDecorator to ensure it's integrated correctly rg --type go 'BlockAddressesDecorator' -A 10 # Description: Search for middleware or handlers that incorporate decorators rg --type go 'middleware' -A 50 | grep 'BlockAddressesDecorator' # Description: Look for any changes in transaction processing pipelines rg --type go 'handler' -A 30 | grep -E 'BlockAddressesDecorator|BlockedMap|GetParams'Length of output: 2671
app/block_address.go (3)
16-16
: Addition ofgetParams
field toBlockAddressesDecorator
The
getParams
function is added to theBlockAddressesDecorator
struct to retrieve parameters from the context. This enhances the decorator's ability to access dynamic configuration.
19-22
: UpdateNewBlockAddressesDecorator
constructor to includegetParams
The constructor now accepts
getParams
as a parameter, ensuring the decorator is properly initialized with access to the necessary parameters.
25-25
: AssigngetParams
in the struct initializationThe assignment of
getParams
within the constructor correctly links the parameter retrieval function to the decorator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
app/block_address.go (2)
16-16
: Consider adding documentation for thegetParams
fieldAdding a comment to explain the purpose of the
getParams
function within theBlockAddressesDecorator
struct will improve code readability and maintainability.
19-22
: Update function documentation to include the new parameterThe
NewBlockAddressesDecorator
function now accepts agetParams
parameter. Please update the function's documentation to describe this parameter and its role in the decorator's behavior.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- app/block_address.go (2 hunks)
🧰 Additional context used
🔇 Additional comments (1)
app/block_address.go (1)
43-50
: Authorization logic correctly restricts access toMsgStoreBlockList
messagesThe added authorization check ensures that only the
CronosAdmin
can submitMsgStoreBlockList
messages. This implementation properly enforces the required access control.
This reverts commit f7405ce.
7c3ac87
👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻
PR Checklist:
make
)make test
)go fmt
)golangci-lint run
)go list -json -m all | nancy sleuth
)Thank you for your code, it's appreciated! :)
Summary by CodeRabbit
New Features
MsgStoreBlockList
messages.MsgUpdateTokenMapping
.Bug Fixes
MsgStoreBlockList
message type.ethermint
API and corrections to account queries and multisig account handling.Tests
MsgStoreBlockList
, including scenarios for valid inputs and error handling.