-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
fix: make RegisterMsgServiceDesc not use the global registry #19835
Conversation
WalkthroughThis update focuses on refining the message service routing within the Cosmos SDK, specifically enhancing the method and message registration processes. It also marks the Changes
Related issues
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
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.
Review Status
Actionable comments generated: 0
Configuration used: .coderabbit.yml
Files selected for processing (3)
- baseapp/msg_service_router.go (3 hunks)
- types/msgservice/msg_service.go (1 hunks)
- types/tx/msgs.go (1 hunks)
Files skipped from review due to trivial changes (1)
- types/tx/msgs.go
Additional comments: 2
types/msgservice/msg_service.go (1)
- 18-31: The implementation of
RegisterMsgServiceDesc
uses a panic for handling type assertion failures. Consider returning an error from the function instead of panicking to allow the caller to handle the error gracefully. This approach aligns better with robust error handling practices.baseapp/msg_service_router.go (1)
- 140-161: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [143-179]
The changes introduce a type consistency check between the type registered with the interface registry and the type in the handler. This is a crucial improvement for ensuring the correctness of the registration process. However, consider encapsulating the type extraction and comparison logic into a separate, well-named function to improve readability and maintainability.
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.
Review Status
Actionable comments generated: 0
Configuration used: .coderabbit.yml
Files selected for processing (1)
- types/msgservice/msg_service.go (1 hunks)
Additional comments: 1
types/msgservice/msg_service.go (1)
- 20-37: The refactored
RegisterMsgServiceDesc
function correctly iterates over service methods and registers their request and response types if they conform to the expected interfaces. This approach aligns with the PR's objective to enhance reliability and correctness in service method registration. However, there are a few areas for improvement and clarification:
Documentation: The function's documentation is clear about its purpose and how it operates. It's important to ensure that the documentation also mentions the specific expectations for the
HandlerType
and the method signatures (i.e., number of input and output parameters) to aid future developers in understanding the constraints and expected structure of theServiceDesc
.Error Handling: The current implementation silently skips methods that do not meet the expected number of input and output parameters. While this might be intended behavior, it could lead to silent failures or misconfigurations going unnoticed. Consider logging a warning or error when a method is skipped due to not meeting the expected signature. This would aid in debugging and ensure that service method registrations are as expected.
Performance Considerations: Reflection is known to be relatively slower compared to direct type assertions and other non-reflective operations. Given that
RegisterMsgServiceDesc
is likely not called in a performance-critical path (usually during initialization), the use of reflection here is acceptable. However, it's good practice to document such decisions, especially in libraries used by a wide range of applications, to inform users of potential performance implications.Conformity with Uber Golang Style Guide: The code generally adheres to the Uber Golang style guide. The naming conventions, error handling, and structure of the code are in line with Go best practices. The use of reflection is justified and well-handled. It's commendable that the code avoids common pitfalls such as using reflection unsafely or ignoring method signature mismatches without any form of notification.
Overall, the changes made in this function are a significant improvement towards ensuring safer and more reliable service method registration. With the addition of documentation and error handling for skipped methods, the function would be further aligned with best practices and more robust against potential misconfigurations.
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.
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.
LGTM
Is there anything blocking this getting merged? Maybe we just need one more review? |
@aaronc your pull request is missing a changelog! |
Description
This fixes issues that could arise if two go types were generated for the same proto type and the wrong ServiceDesc is registered. It uses reflection on the provided service descriptor to do the registration rather than looking things up in the global registry, which is safer. Looking things up in the global registry will just look up whatever type is registered rather than the ones the user tried to register.
Also, in MsgServiceRouter, there is a check added to make sure the same type that was registered with the interface registry is actually used with the service. This could signal errors if the person registered the wrong types for some reason.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
in the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
Summary by CodeRabbit
MsgResponse
interface with a comment for clarity.RegisterMsgServiceDesc
function in themsgservice
package.