I noticed two issues when trying to Amino encode wasm/MsgStoreCode, one that's indicative of an error that needs to be fixed everywhere, and one that essentially means that autogenerating Amino types from protobuf files is impossible (rip).
MsgStoreCode uses AccessConfig, which has an AccessType enum. The AccessConfig encoding is the source of the issue.
For AccessConfig (in cosmwasm/wasm/v1/types.ts), the amino encoders need to change as follows:
toAmino is not using accessTypeToJSON (relevant in the next section)
message.addresses should only be added to the Amino encoding if it's non-empty. this is because the cosmwasm/wasm/v1/types.proto protobuf has repeated string addresses = 3, and it does NOT have (amino.dont_omitempty) = true. for comparison, MsgSubmitProposal in cosmos/gov/v1/tx.proto has a repeated initial_deposit field WITH (amino.dont_omitempty) = true, meaning that it should include an empty array ([]) if there is no deposit included. i believe this holds true everywhere—if a repeated field does NOT have (amino.dont_omitempty) = true, it should only be included in toAmino if it has at least one element.
I believe this omit repeated issue shows up everywhere and can be fixed easily.
Amino types cannot be generated from protobufs alone
Additionally, the accessTypeToJSON and accessTypeFromJSON helper functions themselves are incorrect. The correct functions are:
export function accessTypeFromJSON(object: any): AccessType {
switch (object) {
case 0:
- case "ACCESS_TYPE_UNSPECIFIED":
+ case "Unspecified":
return AccessType.ACCESS_TYPE_UNSPECIFIED;
case 1:
- case "ACCESS_TYPE_NOBODY":
+ case "Nobody":
return AccessType.ACCESS_TYPE_NOBODY;
case 3:
- case "ACCESS_TYPE_EVERYBODY":
+ case "Everybody":
return AccessType.ACCESS_TYPE_EVERYBODY;
case 4:
- case "ACCESS_TYPE_ANY_OF_ADDRESSES":
+ case "AnyOfAddresses":
return AccessType.ACCESS_TYPE_ANY_OF_ADDRESSES;
case -1:
case "UNRECOGNIZED":
default:
return AccessType.UNRECOGNIZED;
}
}
export function accessTypeToJSON(object: AccessType): string {
switch (object) {
case AccessType.ACCESS_TYPE_UNSPECIFIED:
- return "ACCESS_TYPE_UNSPECIFIED";
+ return "Unspecified";
case AccessType.ACCESS_TYPE_NOBODY:
- return "ACCESS_TYPE_NOBODY";
+ return "Nobody";
case AccessType.ACCESS_TYPE_EVERYBODY:
- return "ACCESS_TYPE_EVERYBODY";
+ return "Everybody";
case AccessType.ACCESS_TYPE_ANY_OF_ADDRESSES:
- return "ACCESS_TYPE_ANY_OF_ADDRESSES";
+ return "AnyOfAddresses";
case AccessType.UNRECOGNIZED:
default:
return "UNRECOGNIZED";
}
}
This one is tricky because the real strings for enums are not stored in the protobuf files, instead living in the Go code directly. This is found in x/wasm/types/params.go:
func (a AccessType) String() string {
switch a {
case AccessTypeNobody:
return "Nobody"
case AccessTypeEverybody:
return "Everybody"
case AccessTypeAnyOfAddresses:
return "AnyOfAddresses"
}
return "Unspecified"
}
And digging deeper, we find this other enum string encoding for VoteOption in x/gov/types/v1/gov.pb.go:
...which corresponds to the correct encoders for MsgVote in the gov module, which uses the uppercase enum names.
This reveals that Cosmos SDK modules have no standard for how enums are encoded, and it's up to the module author to decide how to encode an enum. Thus any attempt to autogenerate Amino encoders from protobuf files will fail, and instead it needs to actually parse and construct these types from Go code.
I noticed two issues when trying to Amino encode
wasm/MsgStoreCode
, one that's indicative of an error that needs to be fixed everywhere, and one that essentially means that autogenerating Amino types from protobuf files is impossible (rip).MsgStoreCode
usesAccessConfig
, which has anAccessType
enum. TheAccessConfig
encoding is the source of the issue.For
AccessConfig
(incosmwasm/wasm/v1/types.ts
), the amino encoders need to change as follows:Notice how:
toAmino
is not usingaccessTypeToJSON
(relevant in the next section)message.addresses
should only be added to the Amino encoding if it's non-empty. this is because thecosmwasm/wasm/v1/types.proto
protobuf hasrepeated string addresses = 3
, and it does NOT have(amino.dont_omitempty) = true
. for comparison,MsgSubmitProposal
incosmos/gov/v1/tx.proto
has a repeatedinitial_deposit
field WITH(amino.dont_omitempty) = true
, meaning that it should include an empty array ([]
) if there is no deposit included. i believe this holds true everywhere—if a repeated field does NOT have(amino.dont_omitempty) = true
, it should only be included intoAmino
if it has at least one element.I believe this omit repeated issue shows up everywhere and can be fixed easily.
Amino types cannot be generated from protobufs alone
Additionally, the
accessTypeToJSON
andaccessTypeFromJSON
helper functions themselves are incorrect. The correct functions are:This one is tricky because the real strings for enums are not stored in the protobuf files, instead living in the Go code directly. This is found in
x/wasm/types/params.go
:And digging deeper, we find this other enum string encoding for
VoteOption
inx/gov/types/v1/gov.pb.go
:...which corresponds to the correct encoders for MsgVote in the gov module, which uses the uppercase enum names.
This reveals that Cosmos SDK modules have no standard for how enums are encoded, and it's up to the module author to decide how to encode an enum. Thus any attempt to autogenerate Amino encoders from protobuf files will fail, and instead it needs to actually parse and construct these types from Go code.