Skip to content
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

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

Open
1 task done
freak12techno opened this issue Oct 8, 2024 · 0 comments
Open
1 task done
Labels

Comments

@freak12techno
Copy link
Contributor

Is there an existing issue for this?

  • I have searched the existing issues

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 freak12techno changed the title [Bug]: Unmarshalling a JSON with extra fields fails [Bug]: Unmarshalling an LCD JSON response with extra fields into cosmos-sdk types fails Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 📋 Backlog
Development

No branches or pull requests

1 participant