refactor(schema)!: move bech32 address prefixes to a higher level #21026
Conversation
WalkthroughWalkthroughThe recent changes streamline the codebase by removing the Changes
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 Configuration File (
|
| // AddressKind represents an account address and must be of type []byte. Addresses usually have a | ||
| // human-readable rendering, such as bech32, and tooling should provide a way for apps to define a | ||
| // string encoder for friendly user-facing display. | ||
| AddressKind |
There was a problem hiding this comment.
Most user facing addresses are simply account addresses, but in staking we do have validator addresses exposed to users. Two approaches to handling this are:
- add a separate
ValidatorAddressKind- this would mirror x/tx which supports only account and validator address - allow some open ended list of address types as
Fieldoptions - this could be useful if we expect apps will expose other address types because validator and account addresses in queries
There was a problem hiding this comment.
Anyone have an opinion here? Kind of leaning towards 1. I don't think it's great practice to proliferate lots of bech32 prefixes in one app. They're all account addresses in the end
![coderabbitai[bot]](https://github.com/avatars/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (4)
- schema/field.go (2 hunks)
- schema/field_test.go (1 hunks)
- schema/kind.go (4 hunks)
- schema/kind_test.go (2 hunks)
Additional context used
Path-based instructions (4)
schema/field.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/field_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/kind_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/kind.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Additional comments not posted (11)
schema/field.go (2)
Line range hint
14-35:
LGTM! Simplified validation logic.The removal of the
AddressPrefixfield and its associated validation logic simplifies theValidatemethod. The remaining validation logic appears correct and complete.
Line range hint
37-55:
LGTM! Comprehensive value validation.The
ValidateValuemethod correctly handles null values, validates the value type, and performs additional validation for enum types. The logic appears correct and complete.schema/field_test.go (2)
Line range hint
7-48:
LGTM! Removed obsolete test cases.The removal of test cases related to the
AddressPrefixfield is consistent with the changes in theFieldstruct. The remaining test cases cover all other validation scenarios.
Line range hint
50-114:
LGTM! Comprehensive value validation tests.The test cases in
TestField_ValidateValuecover all validation scenarios for theValidateValuemethod. The logic appears correct and complete.schema/kind_test.go (3)
Line range hint
7-26:
LGTM! Comprehensive kind validation tests.The test cases in
TestKind_Validatecover all validation scenarios for theValidatemethod. The logic appears correct and complete.
Line range hint
28-96:
LGTM! Updated kind validation tests.The test cases for
Bech32AddressKindhave been correctly updated toAddressKind. The remaining test cases cover all validation scenarios for theValidateValueTypemethod.
Line range hint
198-220:
LGTM! Updated kind string tests.The test cases for
Bech32AddressKindhave been correctly updated toAddressKind. The remaining test cases cover all scenarios for theStringmethod.schema/kind.go (4)
75-78: LGTM! The renaming improves clarity.The renaming of
Bech32AddressKindtoAddressKindand the updated comments enhance the readability and flexibility of the code.
153-153: LGTM! The update ensures consistency.The change from
Bech32AddressKindtoAddressKindin theString()method ensures consistency with the renamed constant.
257-257: LGTM! The update ensures consistency.The change from
Bech32AddressKindtoAddressKindin theValidateValueTypemethod ensures consistency with the renamed constant.
324-324: LGTM! The comment update ensures accuracy.The updated comment in the
KindForGoValuefunction accurately reflects the renaming ofBech32AddressKindtoAddressKind.
Description
This is a small refactor of address handling in
schemawhich does not require modules to specify bech32 address prefixes. I see this as preferable because it moves handling of bech32 rendering to a higher level. Ideally, modules should not need to care how addresses are rendered for clients and should not need to know about bech32 prefixes or whether the standardized address encoding is even bech32. With this design, indexers would receive an address codec instance and use that for all modules and objects in an app when indexing.One thing that remains to be decided with this new approach is how to handle other types of addresses such as validator addresses.
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.
Please see Pull Request Reviewer section in the contributing guide for more information on how to review a pull request.
I have...
Summary by CodeRabbit
New Features
Bug Fixes
AddressPrefix, simplifying the validation process for various field types.Documentation