cosmos / cosmos-sdk

:chains: A Framework for Building High Value Public Blockchains :sparkles:
https://cosmos.network/
Apache License 2.0
6.3k stars 3.64k forks source link

Unmarshalling an LCD JSON response with extra fields into cosmos-sdk types fails #22179

Open freak12techno opened 1 month ago

freak12techno commented 1 month ago

Is there an existing issue for this?

What happened?

I faced an issue when I try to fetch some data via API and unmarshal it into cosmos-sdk types. If a structure has extra fields, the message would fail to parse due to this extra fields.

Example: I try to fetch Jackal's mint params via this endpoint https://api.jackal.quokkastake.io/cosmos/mint/v1beta1/params, and they added some of their own fields, which makes the decoder fail to unmarshal it. Here's the relevant part of the code that I am using:

import (
    "github.com/cosmos/cosmos-sdk/codec"
    codecTypes "github.com/cosmos/cosmos-sdk/codec/types"
    "github.com/cosmos/cosmos-sdk/std"
)

...

interfaceRegistry := codecTypes.NewInterfaceRegistry()
std.RegisterInterfaces(interfaceRegistry)
// some similar imports

parseCodec := codec.NewProtoCodec(interfaceRegistry)

// fetching data from this endpoint, receiving an array of bytes
// and trying to unmarshal it:
decodeErr := parseCodec.UnmarshalJSON(bytes, target)

This yields the following error:

12:58AM WRN JSON unmarshalling failed error="unknown field \"dev_grants_ratio\" in types.Params" chain=jackal component=rpc url=https://api.jackal.quokkastake.io/cosmos/mint/v1beta1/params

For Jackal it's understandable, because they added some of their own fields, but I also faced in on Hub when using a vanilla cosmos-sdk, not Hub's fork including LSM stuff, with which I have /cosmos/staking/v1beta1/validators query failing because there's an extra liquid_shares field added by Hub. And I cannot include both Jackal and Hub's cosmos-sdk versions because of Golang limitations (it cannot install two versions of the same library with the same major version), and if I could, that would be soooo wrong.

Globally speaking, when SDK is adding an extra field, and the tools using SDK are not updated properly, that would break the compatibility if trying to use the older SDK on a LCD with a newer SDK.

It would be lovely if there's a setting or param or something similar that is passed to NewProtoCodec, and with it passed, if there are any extra fields, they would be just omitted. Is that possible?

If I am missing something and it's already possible, please let me know.

Cosmos SDK Version

0.45, 0.50

How to reproduce?

See above.

freak12techno commented 1 month ago

@julienrbrt @kocubinski any news here?