You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AutoCLI seems to have issues with Any types in responses. Specifically, it returns the inner types as Amino definitions instead of Proto serialized definitions. I have validated this on a number of AutoCLI chains.
Right, so we use the amino json encoder, so this is the normal behavior of that json marshaller.
However, I agree that is something we can improve.
I won't keep this as a bug, but indeed as an enhancement. Let's track it in that issue 👍🏾, we'll look into it.
julienrbrt
changed the title
[Bug]: AutoCLI incorrectly deserializes Proto types into Amino types
AutoCLI deserializes Proto types into Amino types
Aug 12, 2024
My only argument against it being an enhancement vs a regression is that the v47 feegrant and authz query CLI commands returned Proto json, and these new replacement AutoCLI cmds do not. If you are using the outputs of the CLI with any expectation, for instance with interchain-test, they will break
Is there an existing issue for this?
What happened?
AutoCLI seems to have issues with
Any
types in responses. Specifically, it returns the inner types as Amino definitions instead of Proto serialized definitions. I have validated this on a number of AutoCLI chains.This may be related to #18310
Cosmos SDK Version
0.50.8
How to reproduce?
The expectations here are that
type
is@type
and the value for that key is the proto message name, not the amino registered nameOne example is here:
The text was updated successfully, but these errors were encountered: