feat: index proposals

[wgwz]

Closes: #15

[wgwz]

Looking good. How are you testing this? One thing I never got around to with my prototype was testing to make sure the final status of the proposal is stored correctly, which is probably updated before being pruned but there might be some edge cases.

@ryanchristo I'm just running a version of the script you had written for submitting group proposals. I basically adapted that in small ways for my local setup. But it's doing the exact same thing. At the end of the day all I really cared about for testing this was that in my local setup I was getting the EventProposalPruned etc.. After detecting these events in the indexer, I just issue the API call to find the state of the proposal in the block prior to when the "pruning" occurred. Are you talking about the edge case that Cory mentioned a while ago?

Worth noting there is an edge case that may be tricky to nail down with this approach. Proposals that are submitted with —try exec where a member’s vote is sufficient to pass a proposal might not actually ever have the proposal in state at any height at all. It’s Debatable if this use case is even something worth tracking as a “proposal” in the UI. But we should at least track the edge case in GitHub it if we do move fwd with the implementation you outline here. ref

If so, I think we can just open an issue for that and put it through prioritization rather than fixing it here. But if you're thinking of something else, LMK!

[wgwz]

Did we decide to leave off the votes for now? In the groups-ui app, we expect to be able to show the votes for a given proposal

@blushi i just haven't thought about the votes part of this yet. so if we're going the route of adhering to the interfaces you shared, i guess that the votes info shows up in final_tally_result. we'll just have to make sure that data is delivered in the correct format. i'll give this a try

[blushi]

Did we decide to leave off the votes for now? In the groups-ui app, we expect to be able to show the votes for a given proposal

@blushi i just haven't thought about the votes part of this yet. so if we're going the route of adhering to the interfaces you shared, i guess that the votes info shows up in final_tally_result. we'll just have to make sure that data is delivered in the correct format. i'll give this a try

The thing is that the UI expects more info than just the final tally result, see screenshot below:

So at this point either we simplify the UI as part of the MVP so we only show the final tally result (number of yes/no/etc. votes) for historical proposals or we need to also index votes. By the way, currently, we display the current weight of the voter, but the weight could have been different at the time of the vote (in case of group member update after the vote), so the current implementation is a bit flawed... Because I guess we would want to display the weight of the voter at the time of the vote instead on the proposal page. cc/ @erikalogie @ryanchristo

[wgwz]

The thing is that the UI expects more info than just the final tally result, see screenshot below:

So at this point either we simplify the UI as part of the MVP so we only show the final tally result (number of yes/no/etc. votes) for historical proposals or we need to also index votes. By the way, currently, we display the current weight of the voter, but the weight could have been different at the time of the vote (in case of group member update after the vote), so the current implementation is a bit flawed... Because I guess we would want to display the weight of the voter at the time of the vote instead on the proposal page. cc/ @erikalogie @ryanchristo

I see so I guess this would mean that we need to know the block height at the time the voter cast their vote, so we could then look up the weight at that block height (AKA time). Is there a way we can find out that block height without indexing votes? If so, I'm thinking we could use x-cosmos-block-height header in a REST API call to look up the weight using one of these endpoints:

[blushi]

So in this case i think we would need to look at the https://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.group.v1#cosmos.group.v1.EventVote events, get the vote information as well as the voter weight at that height and then index the vote (noting that a vote can be changed) But let's first see with @erikalogie whether we can skip this part for now and just display the final tally result on the proposal page instead.

[wgwz]

So in this case i think we would need to look at the https://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.group.v1#cosmos.group.v1.EventVote events, get the vote information as well as the voter weight at that height and then index the vote (noting that a vote can be changed) But let's first see with @erikalogie whether we can skip this part for now and just display the final tally result on the proposal page instead.

@blushi i spoke with @ryanchristo about this some more today, and we agreed that it's probably best to track this in separate issue. i think we can probably wrap up a version of this proposals indexing work that doesn't have the votes part in it initially.

[blushi]

So in this case i think we would need to look at the https://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.group.v1#cosmos.group.v1.EventVote events, get the vote information as well as the voter weight at that height and then index the vote (noting that a vote can be changed) But let's first see with @erikalogie whether we can skip this part for now and just display the final tally result on the proposal page instead.

@blushi i spoke with @ryanchristo about this some more today, and we agreed that it's probably best to track this in separate issue. i think we can probably wrap up a version of this proposals indexing work that doesn't have the votes part in it initially.

Sounds good to me too!