cosmos-sdk: gov/v1beta1/proposal doesn't handle correctly new SoftwareUpgradeProposal
Summary of Bug
ping.pub and Kepler explorer crash when opening a governance page, when there is a new SoftwareUpgradeProposal (submitted as a new tx gov submit-proposal) as well as any new proposal gov message. The exception in the browser console is: TypeError: t.p.contents is null. Example.
Probably other explorers (mintscan…) will crash as well.
The reason is that gov/v1beta1/proposals endpoint doesn’t set Content for the new Proposal types.
The problem is that today, explorers use gov/v1beta1/proposals and expect Proposal.Content.
Ecosystem bugs:
- It makes one of the most important features: gov almost unusable without a frontend.
- Without that, literally nobody should use new gov system (they should be marked experimental, until ecosystem adoption is achieved, rather then deprecating the “working” solutions).
- We need an ecosystem push for tooling update.
Version
v0.46.7 I guess, v0.47-alpha2 has same issue.
Steps to Reproduce
-
Start
simd -
Make proposal upgrade:
simd tx gov submit-proposal p.json \ --from w1 --chain-id $CHAINID -y --keyring-backend test --home $APP_HOME --fees 5000$DENOM -b block -
wait until upgrade, and start new binary with compiled upgrade plan, and API server enabled
-
Open ping pug gov page - it will break
-
You won’t be able to see details of any new gov proposal, until explorer will start supporting
gov/v1
Open 127.0.0.1:1317/cosmos/gov/v1/proposals/1, you will see correct response:
{
"proposal": {
"id": "1",
"messages": [
{
"@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade",
"authority": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
"plan": {
"name": "v3.0.0",
"time": "0001-01-01T00:00:00Z",
"height": "45",
"info": "",
"upgraded_client_state": null
}
}
],
"status": "PROPOSAL_STATUS_PASSED",
"final_tally_result": {
"yes_count": "1090000000000",
"abstain_count": "0",
"no_count": "0",
"no_with_veto_count": "0"
},
"submit_time": "2022-12-15T23:20:00.636433951Z",
"deposit_end_time": "2022-12-15T23:21:00.636433951Z",
"total_deposit": [
{
"denom": "stake",
"amount": "10000000"
}
],
"voting_start_time": "2022-12-15T23:20:00.636433951Z",
"voting_end_time": "2022-12-15T23:20:20.636433951Z",
"metadata": ""
}
}
open 127.0.0.1:1317/cosmos/gov/v1beta1/proposals/1, you will see response with null content
{
"proposal": {
"proposal_id": "1",
"content": null,
"status": "PROPOSAL_STATUS_PASSED",
"final_tally_result": {
"yes": "1090000000000",
"abstain": "0",
"no": "0",
"no_with_veto": "0"
},
"submit_time": "2022-12-15T23:20:00.636433951Z",
"deposit_end_time": "2022-12-15T23:21:00.636433951Z",
"total_deposit": [
{
"denom": "stake",
"amount": "10000000"
}
],
"voting_start_time": "2022-12-15T23:20:00.636433951Z",
"voting_end_time": "2022-12-15T23:20:20.636433951Z"
}
}
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 3
- Comments: 23 (5 by maintainers)
Keplr Dashboard already supports the
v1beta1endpoint. Released an update allowingcontentto benullso this should be no issue on the Keplr side now.Mintscan is looking into it and will prepare against this issues.
thanks for ping us. @hxrts
@liangping if you don’t support
gov/v1endpoint then you won’t show title and description (however I’ve prepared a patch to handle that for messages with explicit title and description content).Haven’t.
@robert-zaremba I think we have patched the null content issue, You need put a sdk version >0.46.6 in the chain.json. let me know if it still not work.
Regarding the metadata, We haven’t figured out what is a practical way to implement, Because there are some common issues (availability, cors) on parsing contents the external link.
The only thing I would suggest is putting title out of the metadata, using a separated field and storing it on chain. that keep minimum necessary info about the proposal. also help display on front-end, especially for iteration.
Changes for gov v1 always needed to be implemented by explorers. For instance, they need to implement metadata changes: https://github.com/cosmos/cosmos-sdk/issues/11301
@amaurym can lend some help, but v1 is a breaking change and was expected to cause some breaking changes. We can look into what can be done, but also a nil check on explorers can be done.