[x/group] Try to execute proposal on submission

[blushi]

We could add some tryExec flag to try to execute a proposal on submission.

ref: regen-network/cosmos-modules#53

[blushi]

@clevinson and I were talking about this issue and we were wondering what should be the behavior in the following use case:

• We have a group account with a ThresholdDecisionPolicy with 3 as threshold and each group member has a weight of 1
• A proposal is submitted for this group account which should be executed immediately
• If we have only 2 signers (considered as yes votes), this is not sufficient for the proposal to pass per the decision policy, but should we store those votes in state so that a third voter could vote independently after that for the proposal to get executed?

cc/ @aaronc

[robert-zaremba]

My understanding, based on: regen-network/cosmos-modules#53, is that:

• we want to send a transaction with multiple vote messages: voters will interact and sign transactions off-chain.
• execute immediately in the same transaction.

So, by the spec, the transaction should fail if it can't execute immediately. Hence we won't store the votes.

However we may consider modifying the spec, and use variant flag:

--exec = {try, must}

If --exec=must - it will follow the interpretation above, if --exec=try - it will store the votes and enable future voting for that proposal.

[blushi]

My understanding, based on: regen-network/cosmos-modules#53, is that:

• we want to sent a transaction with multiple vote messages: voters will interact and sign transactions off-chain.
• execute immediately in the same transaction.

My understanding is rather that when creating a new proposal, the signers of the Msg/CreateProposal request message would be considered as yes votes (the proposers). But yes that means that they will need to sign this transaction off-chain.

So, by the spec, the transaction should fail if it can't execute immediately. Hence no won't store the votes.

However we may consider modifying the spec, and use variant flag:

--exec = {try, must}

If --exec=must - it will follow the interpretation above, if --exec=try - it will store the votes and enable future voting for that proposal.

Yes, that would make sense. Any thoughts @aaronc @clevinson?

[blushi]

I've been thinking through it a little bit, and I'm wondering if this --exec=try would really be useful from a user perspective. I guess that if some group uses this feature, it will likely make sure that the proposal will pass beforehand.

On another note, adding a new msg just for this, eg MsgVoteAndExec instead of using the existing MsgCreateProposal with some specific flag, could also be better from a user standpoint, because it makes it more explicit (eg when signing a transaction on a Ledger).

cc/ @robert-zaremba @clevinson @aaronc

[robert-zaremba]

I'm also more in favor of doing only --exec=must (or just --exec).

[aaronc]

I don't have a strong preference but the use case I'm considering is when a user has all the voting power signing a single transaction to propose, vote and execute all at once. But, I don't think there's harm in trying to execute all at once and instead storing the votes for further approval if that fails. It seems like that behavior would save the round trip of querying what the current voting power is and deciding conditionally based on that. So my original design was always "try exec" rather than "must exec".

Also I would just note that I believe there should be a "try exec" option both on submit proposal and on vote. So I guess my preference is generally "try exec" vs "must exec". I'm not sure why the proposer would want to just give up if they don't have enough voting power. But I'm open to counter-arguments.

[blushi]

@aaronc Yes your points make sense. So we would basically add the "try exec" option to both MsgCreateProposal and MsgVote requests.

[aaronc]

@aaronc Yes your points make sense. So we would basically add the "try exec" option to both MsgCreateProposal and MsgVote requests.

Exactly

[robert-zaremba]

I thought that the main use-case is to execute immediately in [...] an atomic transaction - so that's why I proposed to have --exec=must (because it directly provides a solution for that use-case) and --exec=try for more options for a user.

We can always start with one option and implement other later if we want to limit the scope.