Proposals cannot be executed based on quorum after voting period over

[uint]

Proposals can pass early or after the voting period is over. If a proposal doesn't pass early, but after the voting period is over, it will still be Status::Open internally and execute_execute will error.

This affects tgrade-community-pool, tgrade-validator-voting, oc-proposals and cw3-flex-multisig.

The simplest solution is to do something like Ethan's suggestion in #12 - use .current_status() rather than directly comparing the .status field.

More importantly, we need tests for this situation.

[ethanfrey]

yes, tests first and a failing CI run before the fix. 💯
Thanks for looking into this and finding the bug

[uint]

Here's a test case to better illustrate this:

threshold: 50%
quorum: 20%
allow_end_early: doesn't matter

alice: 4 voting power
bob: 6 voting power

1. Alice votes YES, Bob doesn't vote.
2. status = open, because Alice's vote couldn't pass proposal early (4/10 votes are YES, Bob can still reject proposal).
3. Wait for the voting period to end.
4. status = passed (in query, not internally)
5. Anyone should now be able to execute the proposal - 20% quorum was met, 100% cast votes are YES.

[uint]

Bonus points: move the logic around checking/updating statuses in execute_execute to voting-contract somehow, and test it there.

[ethanfrey]

Some of the execute_execute logic is generic, the rest is dispatching the actual proposal.

Maybe we could have a generic execute_execute<P> that checks the status and updates it and then dispatches to some Fn(DepsMut, Env, Info, P) -> Result<Response, E> which is passed as an arg?

This whole issue of extensibility is a bit tricky for me. Whether subclassing, or decorators, or other meta-programming tricks. I find it a bit tricky to extend other code in many places.

[ethanfrey]

Closed by #18