Let proposal_update_operation fail if it approves a proposal but the proposal fails to execute

[mastercyb]

I suppose that proper behavior is not to confirm approval in this case

[abitmore]

UI issue? Report to https://github.com/bitshares/bitshares-ui/issues?

[mastercyb]

Is not UI issue. My point is that the blockchain should not accept such approval throwing error

[abitmore]

It's a feature.

When updating a proposal (add or remove approvals) without a review period(e.g. committee proposals which will only execute on expiration), if the authority threshold is met after the update, the proposal will be tried to execute immediately. If the execution failed, for example due to insufficient fee, the proposal will be left there waiting for future update, or expiration. It will be tried to execute again after another update if still has enough approvals. It will be tried again on expiration. Related code is here

So in your case, you can transfer enough fund to the account then try to approve the proposal again.

Actually, what we need is a method to notify related parties when a proposal is failed to execute.

[abitmore]

@21xhipster IMHO your suggestion makes sense as well. However, changing of behavior requires a hard fork. Hope others join the discussion.

[pmconrad]

IMO the behaviour of the blockchain is OK, because it doesn't break anything. A complete fix in the suggested form is close to impossible, because the problem situation can be created in many different ways.

[abitmore]

About implementation, for example we can re-throw the fc::exception when the proposal is failed to execute, rather than catching it and do nothing.

[xiangxn]

Is there a good way to log errors and return them to the UI? All I can think of is adding fields to proposals.

[abitmore]

Note:

• need to update proposal tests added in Fix #584 authorize transactions with non-immediate owner authorities #1259 after implemented this feature.

[abitmore]

Let's get this done in next consensus-upgrade release. Need a BSIP?

[pmconrad]

At BitFest I was talking with @oxarbitrage about how to automate certain things at the blockchain level, and came up with a use-case that would be destroyed by the proposed change. I think we should keep the current behaviour.

Use-case: Alice wants to automatically transfer a CAKE token to Bob at a specific point in the future (for example as a birthday present).

1. Alice creates "cron" account
2. Alice sends 1 CAKE to cron
3. Alice makes sure cron doesn't have sufficient BTS for a transfer fee
4. Alice proposes that cron sends 1 CAKE to Bob, proposal expires on Bob's birthday
5. Alice sends sufficient BTS for proposal_update to cron
6. cron approves the proposal
7. Proposal fails to execute immediately due to lack of funds for transfer fee
8. Alice sends transfer fee to cron
9. On Bob's birthday the proposal expires and is executed again. Since there is sufficient BTS in cron account for transfer, the execution succeeds and Bob receives his CAKE.

[abitmore]

@pmconrad I don't think it's a good use case, it's made too complicated. If you want a proposal to be executed only on expiration, you can simply set a review period.

[pmconrad]

That's not my point. I think the proposal would cripple current functionality, and I don't see the need.

It's not a bug, so a BSIP is required in any case.

[abitmore]

@pmconrad the reason I think we need this is IMHO it can fix the multiple proposal_update issue.

[jmjatlanta]

Excuse me for being naive, but why not just reply to the caller that the update succeeded, but the proposal has yet to execute successfully? Perhaps with a reason would be even better. I do not see it as an exception, as it is common. I see it as a status.

I believe we have the mechanism to return more than just a simple yes/no result. Does that not give everyone what they want? (no change in functionality, just alert the user)