ICA EncodingType: String vs Enum vs Type Alias #4036
Labels
27-interchain-accounts
change: api breaking
Issues or PRs that break Go API (need to be release in a new major version)
needs discussion
Issues that need discussion before they can be worked on
nice-to-have
Summary
This discussion was started by @chatton in this thread. It has gathered some support (@crodriguezvega ).
Problem Definition
Currently, during the channel handshake, the exchanged version metadata includes an encoding field, serialised as a string. The different values this string could take are defined in
modules/apps/27-interchain-accounts/types/metadata.go
:We have three possible options:
Option 2: Use an Enum
The reason why this is listed as breaking is, even if the enum is defined in a way such that the
.String()
is non-broken such as:This is still breaking because inherently, proto enums are defined as int32 in go. Which means, when using json to encode the version, it will be converted to a number rather than the string
proto3
.Option 3: Type Alias
I think this might be the more sensible option here. This would keep the inherent type as string, but not allow any string to be passed in (unless the string is defined in
metadata.go
as a constant). This solution would look like:I'm not sure if we can use proto extensions to use our alias in protobuf.
Proposal
Take Option 3
For Admin Use
The text was updated successfully, but these errors were encountered: