-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
refactor: remove gogoproto stringer annotations and MarshalYAML
functions
#13850
Conversation
7abd5f5
to
d0f0e1d
Compare
MarshalYAML
functions
My main concerns of removing some |
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.
Thanks! Removing this proto annotation feels great.
My main concerns of removing some .String() methods, is that the generated String() methods, is sometimes less human-readable. Are we okay with that?
Yes, I think the consensus in #12908 was that the trade-off is reasonable. Morever, if people want more human-friendliness, they can always go the JSON->YAML route.
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, thank for this cleanup
c976491
to
06a7d61
Compare
[Cosmos SDK] SonarCloud Quality Gate failed. |
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
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.
have we checked if the string versions were compatible? we should document some of the breaking formats, if there are any(?).
I think the stable query checks would have caught on some of the strings in staking.
String results are different because they are differently stringified. Here they however contain all same values. I can look further into staking, but note that not all Stringer have been removed for that exact reason (because sometimes the amount of returned contains less information than using the proto generated String method - I need to look at what is the impact of that). Are chains dev using Strings methods for any other reason than display? |
It should be fine, worried mainly that it breaks an endpoint for users and we aren't aware of it. |
I'm not worried about endpoints, we generally use protobuf (not .String) for them. I'm slightly more worried about state-machine, like @julienrbrt pointed out:
I think in the SDK we're fine, we have 2-3 instances like this one, where we use Maybe we can add a small note in the changelog/upgrading guide to tell chain devs to double-check they are not doing this anymore? |
Description
Follow-up of cosmos/gogoproto#24 / #10965
Fix tests mentioning #10965 by using
.String()
instead of marshalling and unmarshalling for comparing value.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...
!
to 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...
!
in the type prefix if API or client breaking change