Open pharr117 opened 1 year ago
Relating this to #22, it may be better to handle the data by building this type of structure
[
{
"type": "mainnet",
"network": "cosmoshub",
"rpc_server": "[https://cosmoshub-rpc.lavenderfive.com:443](https://cosmoshub-rpc.lavenderfive.com/)",
"rest_server": "https://rest-cosmoshub.goldenratiostaking.net/",
"latest_block_height": 16964901,
"upgrade_found": true,
"active_upgrade_proposals": [
<array of active upgrade proposals if they exist>
],
"current_plan": {
<current plan data if it exists>
}
}
]
Cosmos handles upgrades by scheduling a plan. There can only ever be 1 plan in place, see here for why:
https://github.com/cosmos/cosmos-sdk/blob/5eaa7b8d3c50eefc5dd95210c38c84c1e829509f/x/upgrade/keeper/keeper.go#L185-L189
However, there may be an active proposal being voted on while a current plan is in place. The code currently prefers the active proposal over the current plan, returning data only on that:
https://github.com/DefiantLabs/cosmos-upgrades/blob/18197052b24f9d07ddc1a9b0b8b9c80b1979d5e1/app.py#L563-L579
We should handle both these cases and return data on both instead of just one.