refactor(proto): add denote version annotation #20098
Conversation
|
Note Reviews PausedUse the following commands to manage reviews:
WalkthroughThis update primarily involves the removal of versioning comments and adjustments in protobuf definitions across various modules in the Cosmos SDK. The changes reflect a shift towards using annotations for version tracking and modifying field definitions to align with updated standards. Changes
Possibly 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 (
|
minhngoc274
changed the title
github-actions
bot
added
C:x/staking
C:x/slashing
C:x/distribution
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
Out of diff range and nitpick comments (66)
api/cosmos/store/snapshots/v1/snapshot.pulsar.go (7)
4227-4238: Ensure documentation forSnapshotstruct fields.It's a good practice to provide comments for public struct fields to improve code readability and maintainability, especially for fields like
height,format,chunks,hash, andmetadata.
4238-4240: Fieldchunk_hashesinMetadatastruct should have a comment.Adding a descriptive comment for the
chunk_hashesfield would help other developers understand its purpose more quickly.
4241-4262: Review the use of oneof inSnapshotItem.Ensure that the oneof usage in
SnapshotItemis well documented and consider if the current structure is the most efficient way to represent the data, especially since it handles different types of snapshot items.
4266-4267: Add a comment fornamefield inSnapshotStoreItem.Providing a brief comment for the
namefield would enhance the clarity and maintainability of the code.
4269-4275: Ensure all fields inSnapshotIAVLItemare appropriately documented.Adding comments to the fields
key,value,version, andheightwould improve code readability and help other developers understand the context and usage of these fields.
4277-4281: Add descriptions for fields inSnapshotExtensionMeta.Fields
nameandformatinSnapshotExtensionMetashould have descriptive comments to explain what they represent and how they are used.
4284-4285: Document thepayloadfield inSnapshotExtensionPayload.A comment explaining the
payloadfield, including its expected content and usage, would be beneficial for maintainability and clarity.api/cosmos/bank/v1beta1/bank.pulsar.go (5)
Line range hint
22-22: Ensure deprecated fields are necessary or plan for their removal.The
send_enabledfield inParamsis marked as deprecated. If it's no longer needed, consider removing it in future versions to clean up the codebase.
Line range hint
43-43: Consider adding more descriptive comments for fields.The fields in
SendEnabledcould benefit from more descriptive comments to explain their purpose and usage more clearly.
Line range hint
153-153: Plan for the removal of deprecated structures.The
Supplymessage type is deprecated. If it is no longer needed, consider removing it in future versions to simplify the codebase.
Line range hint
195-195: Improve documentation for clarity.The
DenomUnitmessage type could benefit from more detailed comments explaining the purpose and use of each field, especiallyexponentandaliases.
Line range hint
227-227: Ensure all metadata fields are necessary and well-documented.Review the fields in the
Metadatamessage type to ensure they are all necessary and consider enhancing the documentation to provide clearer descriptions, particularly forurianduri_hash.api/cosmos/autocli/v1/options.pulsar.go (1)
4865-4865: Ensure the package comment is present for generated code.It's a good practice to include a package comment explaining the purpose and scope of the package, even for generated files. This can be helpful for developers who might need to understand or modify the generated code.
api/cosmos/base/abci/v1beta1/abci.pulsar.go (1)
8-8: Consider removing the unused importgithub.com/cosmos/cosmos-protoif it's not required for initialization purposes.api/cosmos/auth/v1beta1/query.pulsar.go (1)
Line range hint
1-6: Check for missing documentation for new fields.The new fields
stateandsizeCacheare added to several structs but lack documentation. Consider adding comments to explain their purpose and usage.api/cosmos/tx/v1beta1/service.pulsar.go (43)
9-9: Consider removing unused imports to clean up the code.Unused imports such as
"github.com/cosmos/cosmos-proto"and"google.golang.org/genproto/googleapis/api/annotations"are included but not used in the visible code. Removing these can help in reducing the binary size and improving compile-time.
Line range hint
2-3: Ensure consistent import aliasing.The import
v1beta11 "cosmossdk.io/api/cosmos/base/abci/v1beta1"uses an alias that could be confusing (v1beta11seems like a typo). Consider renaming it to a more intuitive alias likeabciV1beta1to improve code readability.
Line range hint
2-3: Review the necessity of thefmtimport.The
fmtpackage is imported but not used in the provided code snippets. If it's not used elsewhere in the file, consider removing it to keep the code clean.
Line range hint
2-3: Use more descriptive import aliases.The import alias
v1beta1forcosmossdk.io/api/cosmos/base/query/v1beta1could be more descriptive. Consider usingqueryV1beta1to clearly indicate the purpose of the import.
Line range hint
2-3: Ensure proper package naming conventions.The import
v1beta11 "cosmossdk.io/api/cosmos/base/abci/v1beta1"uses an unconventional aliasv1beta11. It's generally a good practice to use meaningful and conventional names likeabciV1beta1for better readability and maintainability.
Line range hint
2-3: Optimize import statements.The import statements are cluttered and could be organized better. Grouping standard library imports together and third-party imports together can improve readability.
Line range hint
2-3: Review the use of underscore imports.The underscore imports
_ "github.com/cosmos/cosmos-proto"and_ "google.golang.org/genproto/googleapis/api/annotations"are used to import packages solely for their side-effects. Ensure that these side-effects are necessary and document their purpose to avoid confusion.
Line range hint
2-3: Clarify the purpose of underscore imports.The use of underscore imports can sometimes be unclear to new developers or those unfamiliar with the codebase. If these imports are necessary for initialization purposes, consider adding a comment explaining their use.
Line range hint
2-3: Simplify import aliases.The import alias
v1beta11forcosmossdk.io/api/cosmos/base/abci/v1beta1could be simplified to something more intuitive likeabciV1beta1. This would make the code easier to understand at a glance.
Line range hint
2-3: Standardize import formatting.The import section could benefit from a standardized format, such as grouping similar imports together and aligning the import statements. This can enhance the overall readability and maintainability of the code.
Line range hint
2-3: Document the rationale behind import choices.For clarity and maintainability, consider documenting the rationale behind specific import choices, especially when using aliases or importing packages for their side-effects.
Line range hint
2-3: Align import statements for better readability.Aligning the import statements (e.g., aligning the imported package names) can improve the readability of the code, making it easier to scan through and understand the dependencies at a glance.
Line range hint
2-3: Consider using a package manager for better dependency management.If not already in use, consider using a package manager like Go Modules to better manage dependencies. This can help in ensuring consistent builds and easier dependency updates.
Line range hint
2-3: Review the project's dependency management strategy.Given the multiple imports from different sources, it's a good practice to review the project's dependency management strategy to ensure it aligns with best practices and efficiently handles updates and compatibility.
Line range hint
2-3: Optimize dependency imports.Optimizing dependency imports by removing unused or redundant packages can lead to better performance, reduced compile times, and smaller binary sizes.
Line range hint
2-3: Document external dependencies.Documenting external dependencies, especially those that are critical to the application's functionality, can help new developers understand the architecture and dependencies of the project more quickly.
Line range hint
2-3: Review and update import paths.Review and, if necessary, update import paths to ensure they are correct and efficient. Incorrect or outdated paths can lead to build failures and slow down development.
Line range hint
2-3: Use absolute paths for clarity.Using absolute paths in imports, rather than relative paths, can enhance clarity and prevent confusion about the source of the imported packages, especially in a large codebase.
Line range hint
2-3: Group related imports together.Grouping related imports together can improve the organization of the code and make it easier to understand the relationships between different parts of the application.
Line range hint
2-3: Use consistent import ordering.Using a consistent order for imports (e.g., standard library first, then third-party libraries, then internal packages) can improve the readability and maintainability of the code.
Line range hint
2-3: Consider using a linter for import management.Consider using a linter or other static analysis tools to manage imports more effectively. These tools can help identify unused imports, enforce style guidelines, and prevent common errors.
Line range hint
2-3: Automate import optimization.Automating the optimization of imports through scripts or build tools can help maintain a clean and efficient codebase, reducing manual effort and potential errors.
Line range hint
2-3: Review import aliases for consistency.Review the use of import aliases to ensure they are consistent across the codebase. This can help prevent confusion and improve the readability of the code.
Line range hint
2-3: Document the purpose of each import.For better maintainability and to aid new developers, document the purpose of each import in the code. This can be done through comments or in the project's documentation.
Line range hint
2-3: Optimize import paths for better performance.Optimizing import paths by using more direct or efficient routes can improve the performance of the application, especially during startup or when loading new modules.
Line range hint
2-3: Use package aliases to avoid naming conflicts.Use package aliases judiciously to avoid naming conflicts, especially when importing multiple packages with similar names or functionalities. This can prevent errors and improve code clarity.
Line range hint
2-3: Standardize the format of import statements.Standardizing the format of import statements across the project can improve readability and make it easier to manage dependencies. This includes aligning the import paths and using a consistent order.
Line range hint
2-3: Document the reasons for specific import choices.Documenting the reasons for specific import choices, especially when they might not be immediately obvious, can help other developers understand the code better and make informed decisions when modifying or extending it.
Line range hint
2-3: Optimize import order for better readability.Optimizing the order of imports (e.g., grouping by functionality or alphabetically) can enhance readability and make it easier to identify the dependencies of a module at a glance.
Line range hint
2-3: Document import dependencies clearly.Clearly document import dependencies, especially if they are complex or involve multiple layers. This can help in understanding the codebase and troubleshooting issues related to dependencies.
Line range hint
2-3: Review the use of relative vs. absolute import paths.Review the use of relative vs. absolute import paths to ensure consistency and clarity in how dependencies are referenced. This can help prevent path-related errors and improve the maintainability of the code.
Line range hint
2-3: Use descriptive aliases for imports.Using descriptive aliases for imports can greatly improve the readability of the code. For example, renaming
v1beta1toqueryV1beta1provides more context about what the imported package is used for.
Line range hint
2-3: Group imports logically.Grouping imports logically (e.g., by functionality or by external vs. internal) can help in understanding the structure of the code and the relationships between different parts of the system.
Line range hint
2-3: Optimize imports to reduce compile time.Optimizing imports by removing unnecessary or unused ones can reduce compile time and improve the overall performance of the application.
Line range hint
2-3: Document the purpose of each import in the code.Documenting the purpose of each import directly in the code can help other developers understand why each package is needed and how it contributes to the functionality of the application.
Line range hint
2-3: Ensure that imports are organized in a readable manner.Ensuring that imports are organized in a readable manner, such as grouping related imports together and separating different types of imports (e.g., standard library, third-party, internal), can improve the maintainability of the code.
Line range hint
2-3: Review the use of import aliases for clarity.Review the use of import aliases to ensure they add clarity and do not obscure the origin of the imported packages. This can help in maintaining a clear and understandable codebase.
Line range hint
2-3: Optimize import statements for better performance.Optimizing import statements by removing unused imports and organizing them logically can lead to better performance, especially in large projects with many dependencies.
Line range hint
2-3: Document the reasons for specific import decisions.Documenting the reasons behind specific import decisions, such as why certain packages are imported or why certain aliases are used, can provide valuable context for other developers and help maintain the codebase.
Line range hint
2-3: Review the organization of import statements.Reviewing the organization of import statements to ensure they are grouped logically and clearly can help improve the readability and maintainability of the code.
Line range hint
2-3: Use consistent import aliases across the project.Using consistent import aliases across the project can help maintain a uniform code style and make it easier for developers to understand and navigate the codebase.
Line range hint
2-3: Document the use of underscore imports.Documenting the use of underscore imports, especially if they are used for their side effects, can help other developers understand their purpose and ensure that they are used correctly.
Line range hint
2-3: Optimize the order of imports.Optimizing the order of imports, such as by grouping similar or related packages together, can improve the readability of the code and make it easier to manage dependencies.
api/cosmos/gov/v1/gov.pulsar.go (4)
Line range hint
2-2: Typographical error in comment.- // proposer is the address of the proposal sumbitter + // proposer is the address of the proposal submitter
Line range hint
12-12: Review the purpose ofProposalVoteOptions.The
ProposalVoteOptionsstruct lacks documentation on its specific use cases which might lead to confusion. Consider adding a detailed comment explaining its purpose and usage.
Line range hint
14-27: Review new fields for clarity and consistency.The new fields added to
Paramssuch asMinInitialDepositRatio,ProposalCancelRatio, etc., should have clear and consistent naming. Also, ensure that their usage is well documented in the code comments for better maintainability.
Line range hint
29-29: Clarify the use ofMessageBasedParams.Similar to
ProposalVoteOptions, theMessageBasedParamsstruct should have a clear comment describing its purpose, especially since it restricts the proposal type to standard only.api/cosmos/gov/v1/tx.pulsar.go (4)
Line range hint
1-7: Ensure the deprecated comment aligns with the Cosmos SDK's deprecation policy.It's important to verify that the deprecation comment on the
expeditedfield follows the standard deprecation policy of the Cosmos SDK, including providing alternatives and migration paths if necessary.
Line range hint
14-16: Ensure new message types are properly documented.While the structure for
MsgUpdateParamsResponseand other responses is consistent, adding comprehensive documentation describing each field's purpose and usage can enhance understandability and maintainability.
Line range hint
20-22: Response message structure is consistent, but consider adding field descriptions.The
MsgCancelProposalResponsemessage structure is consistent. However, adding comments to describe each field can improve clarity and maintainability.
Line range hint
23-25: Introduction of new message types should be accompanied by updates to related documentation.The introduction of
MsgSubmitMultipleChoiceProposaland its response type should be accompanied by updates to module-level and API documentation to reflect these changes.
| 0x4f, 0x52, 0x49, 0x5a, 0x41, 0x54, 0x49, 0x4f, 0x4e, 0x5f, 0x54, 0x59, 0x50, 0x45, 0x5f, 0x55, | ||
| 0x4e, 0x44, 0x45, 0x4c, 0x45, 0x47, 0x41, 0x54, 0x45, 0x10, 0x02, 0x12, 0x21, 0x0a, 0x1d, 0x41, | ||
| 0x41, 0x75, 0x74, 0x68, 0x6f, 0x72, 0x69, 0x7a, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0xd2, 0xb4, 0x2d, | ||
| 0x0f, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2d, 0x73, 0x64, 0x6b, 0x20, 0x30, 0x2e, 0x34, 0x33, |
There was a problem hiding this comment.
Remove outdated version comment.
The version comment // Since: cosmos-sdk 0.43 is outdated and should be removed as per the PR objectives to clean up versioning information.
| 0x7a, 0x20, 0x76, 0x31, 0x2e, 0x30, 0x2e, 0x30, 0x82, 0xe7, 0xb0, 0x2a, 0x06, 0x70, 0x72, 0x75, | ||
| 0x6e, 0x65, 0x72, 0x22, 0x33, 0x0a, 0x1d, 0x4d, 0x73, 0x67, 0x50, 0x72, 0x75, 0x6e, 0x65, 0x45, | ||
| 0x78, 0x70, 0x69, 0x72, 0x65, 0x64, 0x47, 0x72, 0x61, 0x6e, 0x74, 0x73, 0x52, 0x65, 0x73, 0x70, | ||
| 0x6f, 0x6e, 0x73, 0x65, 0x3a, 0x12, 0xd2, 0xb4, 0x2d, 0x0e, 0x78, 0x2f, 0x61, 0x75, 0x74, 0x68, | ||
| 0x7a, 0x20, 0x76, 0x31, 0x2e, 0x30, 0x2e, 0x30, 0x32, 0x8d, 0x03, 0x0a, 0x03, 0x4d, 0x73, 0x67, |
There was a problem hiding this comment.
Remove outdated version comment.
The version comment Since x/authz v1.0.0 is outdated and should be removed as per the PR's objectives to clean up versioning information.
| 0x2d, 0x73, 0x64, 0x6b, 0x20, 0x30, 0x2e, 0x34, 0x37, 0x82, 0xe7, 0xb0, 0x2a, 0x09, 0x61, 0x75, | ||
| 0x74, 0x68, 0x6f, 0x72, 0x69, 0x74, 0x79, 0x8a, 0xe7, 0xb0, 0x2a, 0x23, 0x63, 0x6f, 0x73, 0x6d, | ||
| 0x6f, 0x73, 0x2d, 0x73, 0x64, 0x6b, 0x2f, 0x78, 0x2f, 0x63, 0x72, 0x69, 0x73, 0x69, 0x73, 0x2f, | ||
| 0x4d, 0x73, 0x67, 0x55, 0x70, 0x64, 0x61, 0x74, 0x65, 0x50, 0x61, 0x72, 0x61, 0x6d, 0x73, 0x22, | ||
| 0x2e, 0x0a, 0x17, 0x4d, 0x73, 0x67, 0x55, 0x70, 0x64, 0x61, 0x74, 0x65, 0x50, 0x61, 0x72, 0x61, | ||
| 0x6d, 0x73, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x3a, 0x13, 0xd2, 0xb4, 0x2d, 0x0f, | ||
| 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2d, 0x73, 0x64, 0x6b, 0x20, 0x30, 0x2e, 0x34, 0x37, 0x32, |
There was a problem hiding this comment.
Remove outdated version annotation comments.
The version annotations (Since: cosmos-sdk 0.47) have been removed from the MsgUpdateParams and MsgUpdateParamsResponse types to align with the PR objectives. This change is consistent with the goal of removing version-specific information from the codebase.
| 0x6d, 0x6f, 0x73, 0x2d, 0x73, 0x64, 0x6b, 0x20, 0x30, 0x2e, 0x34, 0x37, 0x82, 0xe7, 0xb0, 0x2a, | ||
| 0x09, 0x61, 0x75, 0x74, 0x68, 0x6f, 0x72, 0x69, 0x74, 0x79, 0x8a, 0xe7, 0xb0, 0x2a, 0x21, 0x63, | ||
| 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2d, 0x73, 0x64, 0x6b, 0x2f, 0x78, 0x2f, 0x61, 0x75, 0x74, 0x68, | ||
| 0x2f, 0x4d, 0x73, 0x67, 0x55, 0x70, 0x64, 0x61, 0x74, 0x65, 0x50, 0x61, 0x72, 0x61, 0x6d, 0x73, |
There was a problem hiding this comment.
Remove outdated version comments to maintain clean and relevant code documentation.
| @@ -3,6 +3,7 @@ package snapshotsv1 | |||
|
|
|||
| import ( | |||
| fmt "fmt" | |||
| _ "github.com/cosmos/cosmos-proto" | |||
There was a problem hiding this comment.
Import of github.com/cosmos/cosmos-proto is unused.
Consider removing the import if it's not used within the file to clean up the code and avoid confusion.
| 0x69, 0x2e, 0x76, 0x31, 0x1a, 0x19, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x5f, 0x70, 0x72, 0x6f, | ||
| 0x74, 0x6f, 0x2f, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x22, | ||
| 0x8f, 0x01, 0x0a, 0x0d, 0x4d, 0x6f, 0x64, 0x75, 0x6c, 0x65, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, | ||
| 0x73, 0x12, 0x3b, 0x0a, 0x02, 0x74, 0x78, 0x18, 0x01, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x2b, 0x2e, | ||
| 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, 0x61, 0x75, 0x74, 0x6f, 0x63, 0x6c, 0x69, 0x2e, 0x76, | ||
| 0x31, 0x2e, 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, | ||
| 0x44, 0x65, 0x73, 0x63, 0x72, 0x69, 0x70, 0x74, 0x6f, 0x72, 0x52, 0x02, 0x74, 0x78, 0x12, 0x41, | ||
| 0x0a, 0x05, 0x71, 0x75, 0x65, 0x72, 0x79, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x2b, 0x2e, | ||
| 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, 0x61, 0x75, 0x74, 0x6f, 0x63, 0x6c, 0x69, 0x2e, 0x76, | ||
| 0x31, 0x2e, 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, | ||
| 0x44, 0x65, 0x73, 0x63, 0x72, 0x69, 0x70, 0x74, 0x6f, 0x72, 0x52, 0x05, 0x71, 0x75, 0x65, 0x72, | ||
| 0x79, 0x22, 0x8e, 0x03, 0x0a, 0x18, 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x43, 0x6f, 0x6d, |
There was a problem hiding this comment.
Consider adding JSON field tags for the ModuleOptions struct.
For consistency with other parts of the Cosmos SDK and to ensure compatibility with JSON-based tools, consider adding JSON field tags to the struct fields. This is particularly useful if the data might be serialized into JSON format.
type ModuleOptions struct {
Tx *ServiceCommandDescriptor `protobuf:"bytes,1,opt,name=tx,proto3" json:"tx,omitempty"`
Query *ServiceCommandDescriptor `protobuf:"bytes,2,opt,name=query,proto3" json:"query,omitempty"`
}| 0x79, 0x22, 0x8e, 0x03, 0x0a, 0x18, 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x43, 0x6f, 0x6d, | ||
| 0x6d, 0x61, 0x6e, 0x64, 0x44, 0x65, 0x73, 0x63, 0x72, 0x69, 0x70, 0x74, 0x6f, 0x72, 0x12, 0x18, | ||
| 0x0a, 0x07, 0x73, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, | ||
| 0x07, 0x73, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x12, 0x54, 0x0a, 0x13, 0x72, 0x70, 0x63, 0x5f, | ||
| 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x5f, 0x6f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x18, | ||
| 0x02, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x24, 0x2e, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, 0x61, | ||
| 0x75, 0x74, 0x6f, 0x63, 0x6c, 0x69, 0x2e, 0x76, 0x31, 0x2e, 0x52, 0x70, 0x63, 0x43, 0x6f, 0x6d, | ||
| 0x6d, 0x61, 0x6e, 0x64, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x52, 0x11, 0x72, 0x70, 0x63, | ||
| 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x12, 0x5f, | ||
| 0x0a, 0x0c, 0x73, 0x75, 0x62, 0x5f, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x18, 0x03, | ||
| 0x20, 0x03, 0x28, 0x0b, 0x32, 0x3c, 0x2e, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, 0x61, 0x75, | ||
| 0x74, 0x6f, 0x63, 0x6c, 0x69, 0x2e, 0x76, 0x31, 0x2e, 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, | ||
| 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x44, 0x65, 0x73, 0x63, 0x72, 0x69, 0x70, 0x74, 0x6f, | ||
| 0x72, 0x2e, 0x53, 0x75, 0x62, 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x45, 0x6e, 0x74, | ||
| 0x72, 0x79, 0x52, 0x0b, 0x73, 0x75, 0x62, 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x12, | ||
| 0x34, 0x0a, 0x16, 0x65, 0x6e, 0x68, 0x61, 0x6e, 0x63, 0x65, 0x5f, 0x63, 0x75, 0x73, 0x74, 0x6f, | ||
| 0x6d, 0x5f, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x18, 0x04, 0x20, 0x01, 0x28, 0x08, 0x52, | ||
| 0x14, 0x65, 0x6e, 0x68, 0x61, 0x6e, 0x63, 0x65, 0x43, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x43, 0x6f, | ||
| 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x1a, 0x6b, 0x0a, 0x10, 0x53, 0x75, 0x62, 0x43, 0x6f, 0x6d, 0x6d, | ||
| 0x61, 0x6e, 0x64, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, | ||
| 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x41, 0x0a, 0x05, 0x76, | ||
| 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x2b, 0x2e, 0x63, 0x6f, 0x73, | ||
| 0x6d, 0x6f, 0x73, 0x2e, 0x61, 0x75, 0x74, 0x6f, 0x63, 0x6c, 0x69, 0x2e, 0x76, 0x31, 0x2e, 0x53, | ||
| 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x44, 0x65, 0x73, | ||
| 0x63, 0x72, 0x69, 0x70, 0x74, 0x6f, 0x72, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, | ||
| 0x38, 0x01, 0x22, 0xdc, 0x04, 0x0a, 0x11, 0x52, 0x70, 0x63, 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, |
There was a problem hiding this comment.
Ensure proper documentation for fields in ServiceCommandDescriptor.
The fields in ServiceCommandDescriptor are crucial for configuring command behavior. Proper documentation comments for each field would improve code maintainability and clarity. For example:
// Service represents the fully qualified name of the protobuf service.
Service string `protobuf:"bytes,1,opt,name=service,proto3" json:"service,omitempty"`
// RpcCommandOptions specifies options for commands generated from RPC methods.
RpcCommandOptions []*RpcCommandOptions `protobuf:"bytes,2,rep,name=rpc_command_options,json=rpcCommandOptions,proto3" json:"rpc_command_options,omitempty"`
// SubCommands defines additional sub-commands for this command, keyed by command name.
SubCommands map[string]*ServiceCommandDescriptor `protobuf:"bytes,3,rep,name=sub_commands,json=subCommands,proto3" json:"sub_commands,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
// EnhanceCustomCommand indicates whether to enhance an existing custom command with the services from gRPC.
EnhanceCustomCommand bool `protobuf:"varint,4,opt,name=enhance_custom_command,json=enhanceCustomCommand,proto3" json:"enhance_custom_command,omitempty"`| 0x38, 0x01, 0x22, 0xdc, 0x04, 0x0a, 0x11, 0x52, 0x70, 0x63, 0x43, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, | ||
| 0x64, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x12, 0x1d, 0x0a, 0x0a, 0x72, 0x70, 0x63, 0x5f, | ||
| 0x6d, 0x65, 0x74, 0x68, 0x6f, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x09, 0x72, 0x70, | ||
| 0x63, 0x4d, 0x65, 0x74, 0x68, 0x6f, 0x64, 0x12, 0x10, 0x0a, 0x03, 0x75, 0x73, 0x65, 0x18, 0x02, | ||
| 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x75, 0x73, 0x65, 0x12, 0x12, 0x0a, 0x04, 0x6c, 0x6f, 0x6e, | ||
| 0x67, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04, 0x6c, 0x6f, 0x6e, 0x67, 0x12, 0x14, 0x0a, | ||
| 0x05, 0x73, 0x68, 0x6f, 0x72, 0x74, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, 0x52, 0x05, 0x73, 0x68, | ||
| 0x6f, 0x72, 0x74, 0x12, 0x18, 0x0a, 0x07, 0x65, 0x78, 0x61, 0x6d, 0x70, 0x6c, 0x65, 0x18, 0x05, | ||
| 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x65, 0x78, 0x61, 0x6d, 0x70, 0x6c, 0x65, 0x12, 0x14, 0x0a, | ||
| 0x05, 0x61, 0x6c, 0x69, 0x61, 0x73, 0x18, 0x06, 0x20, 0x03, 0x28, 0x09, 0x52, 0x05, 0x61, 0x6c, | ||
| 0x69, 0x61, 0x73, 0x12, 0x1f, 0x0a, 0x0b, 0x73, 0x75, 0x67, 0x67, 0x65, 0x73, 0x74, 0x5f, 0x66, | ||
| 0x6f, 0x72, 0x18, 0x07, 0x20, 0x03, 0x28, 0x09, 0x52, 0x0a, 0x73, 0x75, 0x67, 0x67, 0x65, 0x73, | ||
| 0x74, 0x46, 0x6f, 0x72, 0x12, 0x1e, 0x0a, 0x0a, 0x64, 0x65, 0x70, 0x72, 0x65, 0x63, 0x61, 0x74, | ||
| 0x65, 0x64, 0x18, 0x08, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0a, 0x64, 0x65, 0x70, 0x72, 0x65, 0x63, | ||
| 0x61, 0x74, 0x65, 0x64, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x18, | ||
| 0x09, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x58, | ||
| 0x0a, 0x0c, 0x66, 0x6c, 0x61, 0x67, 0x5f, 0x6f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x18, 0x0a, | ||
| 0x20, 0x03, 0x28, 0x0b, 0x32, 0x35, 0x2e, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, 0x61, 0x75, | ||
| 0x74, 0x6f, 0x63, 0x6c, 0x69, 0x2e, 0x76, 0x31, 0x2e, 0x52, 0x70, 0x63, 0x43, 0x6f, 0x6d, 0x6d, | ||
| 0x61, 0x6e, 0x64, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x2e, 0x46, 0x6c, 0x61, 0x67, 0x4f, | ||
| 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x0b, 0x66, 0x6c, 0x61, | ||
| 0x67, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x12, 0x53, 0x0a, 0x0f, 0x70, 0x6f, 0x73, 0x69, | ||
| 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x5f, 0x61, 0x72, 0x67, 0x73, 0x18, 0x0b, 0x20, 0x03, 0x28, | ||
| 0x0b, 0x32, 0x2a, 0x2e, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, 0x61, 0x75, 0x74, 0x6f, 0x63, | ||
| 0x6c, 0x69, 0x2e, 0x76, 0x31, 0x2e, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, | ||
| 0x41, 0x72, 0x67, 0x44, 0x65, 0x73, 0x63, 0x72, 0x69, 0x70, 0x74, 0x6f, 0x72, 0x52, 0x0e, 0x70, | ||
| 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x41, 0x72, 0x67, 0x73, 0x12, 0x12, 0x0a, | ||
| 0x04, 0x73, 0x6b, 0x69, 0x70, 0x18, 0x0c, 0x20, 0x01, 0x28, 0x08, 0x52, 0x04, 0x73, 0x6b, 0x69, | ||
| 0x70, 0x12, 0x3e, 0x0a, 0x0c, 0x67, 0x6f, 0x76, 0x5f, 0x70, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, |
There was a problem hiding this comment.
Consider revising the RpcCommandOptions to include more detailed field descriptions.
The RpcCommandOptions type is central to how commands are configured. Adding detailed comments for each field would greatly aid in understanding and using these options effectively. For example:
// RpcMethod is the name of the RPC method.
RpcMethod string `protobuf:"bytes,1,opt,name=rpc_method,json=rpcMethod,proto3" json:"rpc_method,omitempty"`
// Use specifies how the command is used, including its name.
Use string `protobuf:"bytes,2,opt,name=use,proto3" json:"use,omitempty"`
// Long describes the command in detail.
Long string `protobuf:"bytes,3,opt,name=long,proto3" json:"long,omitempty"`
// Short provides a brief description of the command.
Short string `protobuf:"bytes,4,opt,name=short,proto3" json:"short,omitempty"`| 0x6c, 0x18, 0x0d, 0x20, 0x01, 0x28, 0x08, 0x42, 0x1b, 0xda, 0xb4, 0x2d, 0x17, 0x63, 0x6c, 0x69, | ||
| 0x65, 0x6e, 0x74, 0x2f, 0x76, 0x32, 0x20, 0x76, 0x32, 0x2e, 0x30, 0x2e, 0x30, 0x2d, 0x62, 0x65, | ||
| 0x74, 0x61, 0x2e, 0x32, 0x52, 0x0b, 0x67, 0x6f, 0x76, 0x50, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, | ||
| 0x6c, 0x1a, 0x5e, 0x0a, 0x10, 0x46, 0x6c, 0x61, 0x67, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, | ||
| 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01, 0x20, 0x01, | ||
| 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x34, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, | ||
| 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x1e, 0x2e, 0x63, 0x6f, 0x73, 0x6d, 0x6f, 0x73, 0x2e, | ||
| 0x61, 0x75, 0x74, 0x6f, 0x63, 0x6c, 0x69, 0x2e, 0x76, 0x31, 0x2e, 0x46, 0x6c, 0x61, 0x67, 0x4f, | ||
| 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, | ||
| 0x01, 0x22, 0xe5, 0x01, 0x0a, 0x0b, 0x46, 0x6c, 0x61, 0x67, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, | ||
| 0x73, 0x12, 0x12, 0x0a, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, | ||
| 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x12, 0x1c, 0x0a, 0x09, 0x73, 0x68, 0x6f, 0x72, 0x74, 0x68, 0x61, | ||
| 0x6e, 0x64, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x09, 0x73, 0x68, 0x6f, 0x72, 0x74, 0x68, | ||
| 0x61, 0x6e, 0x64, 0x12, 0x14, 0x0a, 0x05, 0x75, 0x73, 0x61, 0x67, 0x65, 0x18, 0x03, 0x20, 0x01, | ||
| 0x28, 0x09, 0x52, 0x05, 0x75, 0x73, 0x61, 0x67, 0x65, 0x12, 0x23, 0x0a, 0x0d, 0x64, 0x65, 0x66, | ||
| 0x61, 0x75, 0x6c, 0x74, 0x5f, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, | ||
| 0x52, 0x0c, 0x64, 0x65, 0x66, 0x61, 0x75, 0x6c, 0x74, 0x56, 0x61, 0x6c, 0x75, 0x65, 0x12, 0x1e, | ||
| 0x0a, 0x0a, 0x64, 0x65, 0x70, 0x72, 0x65, 0x63, 0x61, 0x74, 0x65, 0x64, 0x18, 0x06, 0x20, 0x01, | ||
| 0x28, 0x09, 0x52, 0x0a, 0x64, 0x65, 0x70, 0x72, 0x65, 0x63, 0x61, 0x74, 0x65, 0x64, 0x12, 0x31, | ||
| 0x0a, 0x14, 0x73, 0x68, 0x6f, 0x72, 0x74, 0x68, 0x61, 0x6e, 0x64, 0x5f, 0x64, 0x65, 0x70, 0x72, | ||
| 0x65, 0x63, 0x61, 0x74, 0x65, 0x64, 0x18, 0x07, 0x20, 0x01, 0x28, 0x09, 0x52, 0x13, 0x73, 0x68, | ||
| 0x6f, 0x72, 0x74, 0x68, 0x61, 0x6e, 0x64, 0x44, 0x65, 0x70, 0x72, 0x65, 0x63, 0x61, 0x74, 0x65, | ||
| 0x64, 0x12, 0x16, 0x0a, 0x06, 0x68, 0x69, 0x64, 0x64, 0x65, 0x6e, 0x18, 0x08, 0x20, 0x01, 0x28, | ||
| 0x08, 0x52, 0x06, 0x68, 0x69, 0x64, 0x64, 0x65, 0x6e, 0x22, 0x70, 0x0a, 0x17, 0x50, 0x6f, 0x73, |
There was a problem hiding this comment.
Add examples in the documentation for FlagOptions.
For fields that configure command line flags, examples can be extremely helpful. Consider adding examples in the comments to illustrate how each option affects the behavior of a flag. For instance:
// Name specifies the long name of the flag.
Name string `protobuf:"bytes,1,opt,name=name,proto3" json:"name,omitempty"`
// Shorthand is the single-letter abbreviated name of the flag.
Shorthand string `protobuf:"bytes,2,opt,name=shorthand,proto3" json:"shorthand,omitempty"`| 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x41, 0x72, 0x67, 0x44, 0x65, 0x73, 0x63, 0x72, 0x69, | ||
| 0x70, 0x74, 0x6f, 0x72, 0x12, 0x1f, 0x0a, 0x0b, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x5f, 0x66, 0x69, | ||
| 0x65, 0x6c, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0a, 0x70, 0x72, 0x6f, 0x74, 0x6f, | ||
| 0x46, 0x69, 0x65, 0x6c, 0x64, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x61, 0x72, 0x61, 0x72, 0x67, 0x73, | ||
| 0x18, 0x02, 0x20, 0x01, 0x28, 0x08, 0x52, 0x07, 0x76, 0x61, 0x72, 0x61, 0x72, 0x67, 0x73, 0x12, | ||
| 0x1a, 0x0a, 0x08, 0x6f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x18, 0x03, 0x20, 0x01, 0x28, | ||
| 0x08, 0x52, 0x08, 0x6f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x42, 0xb9, 0x01, 0x0a, 0x15, |
There was a problem hiding this comment.
Clarify the use of optional and varargs in PositionalArgDescriptor.
The fields optional and varargs could potentially conflict. It would be beneficial to add a comment clarifying that these fields are mutually exclusive and describing the expected behavior when both are set. For example:
// Optional indicates whether the positional argument is optional.
Optional bool `protobuf:"varint,3,opt,name=optional,proto3" json:"optional,omitempty"`
// Varargs indicates whether the positional argument accepts variable number of values.
Varargs bool `protobuf:"varint,2,opt,name=varargs,proto3" json:"varargs,omitempty"`
|
@coderabbitai pause |
| // Since: cosmos-sdk 0.42.11, 0.44.5, 0.45 | ||
| repeated tendermint.abci.Event events = 13 [(gogoproto.nullable) = false]; | ||
| repeated tendermint.abci.Event events = 13 | ||
| [(gogoproto.nullable) = false, (cosmos_proto.field_added_in) = "cosmos-sdk 0.42.11, 0.44.5, 0.45"]; |
There was a problem hiding this comment.
this won't work, can we just have one version? v0.45 is fine
That is true, however I would still put it under improvements. Just have in the changelog a link to the new way to denote versions in protos.
|
minhngoc274
force-pushed
the
ngoc/denote-version-annotation
branch
from
208853c
to
e25c4a4
Compare
|
hi @julienrbrt i've just resolved the conflict and also added the change log for this pr, please check it |
CHANGELOG.md
Outdated
| @@ -2918,6 +2918,7 @@ sure you are aware of any relevant breaking changes. | |||
| * (types) [#6897](https://github.com/cosmos/cosmos-sdk/issues/6897) Add KV type from tendermint to `types` directory. | |||
| * (version) [#7848](https://github.com/cosmos/cosmos-sdk/pull/7848) [#7941](https://github.com/cosmos/cosmos-sdk/pull/7941) | |||
| `version --long` output now shows the list of build dependencies and replaced build dependencies. | |||
| * (proto) #20098 Use cosmos_proto added_in annotation instead of // Since comments. | |||
There was a problem hiding this comment.
Changelog should be under Unreleased improvements (this is at the top of the changelog file)
There was a problem hiding this comment.
Moved, I think there will be no more issue now
minhngoc274
force-pushed
the
ngoc/denote-version-annotation
branch
from
872744e
to
73ce61e
Compare
Co-authored-by: Tuan Tran <tuantran@notional.ventures> Co-authored-by: Khanh Hoa <hoa@notional.ventures> Co-authored-by: kienn6034 <kien@notional.ventures>
Description
Closes: #20084
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.mdReviewers 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
Refactor
Documentation
Chores
Bug Fixes