aragon/court-dashboard

Balance Module: double check actions which do not advance heartbeat

Closed this issue · 4 comments

sohkai commented

We should:

  • Only show the "term behind" heartbeat action in the Clock module if we're more than two terms behind
  • Check which actions in the Balance Module don't update the term, and force the user to sign two transactions (update term, then intended action)

Later on, we can improve the overall experience by adding the multi-transaction signing experience.

fabriziovigevani commented

Update on this, with the new implementation of the clock module, now we expose the current term as the current term from the court contract itself instead of the current term that it's supposed to be assuming that the court has transitioned.

Balance module actions

To give context on this:

The actions that attempt to ensure the curren term (which transitions the court up to 1 term) and hence can be executed even if the court is 1 term behind are:

  • Activate
  • Deactivate

The only action that doesn't attempt to ensure the current term is

  • Withdraw.

Since we use the clock current term to react to balance updates, this means that for example a deactivation request won't be processed until the court actually transitions to or past the deactivation request effective term. So we would be updating the inactive balance only if we are sure that withdrawing won't fail.

Options:

  1. Keep this current behavior

    • Pros: We make sure that if the juror has some inactive balance, will be able to withdraw it no matter the court current term.
    • Cons: If a juror has a deactivation request on going, it won't be updated until the court term is transitioned to or past the effective term and this would happen only if any juror activates or deactivates ANJ (which ensures current term) or they transition the term from the clock module itself so probably we need to expose the heartbeat action at all times instead of only if we are 2 or more terms behind.

  2. Revert back to exposing clock current term as the term that it's supposed to be, assumed that court transitions instantly (This would mean that deactivation requests would process as soon as the clock term changes no mattering whether the court term is synced or not):

    • Pros: Jurors don't have to wait for the court to be at or past the deactivation request effective term.
    • Cons: We must make jurors to heartbeat the court when they are trying to withdraw and court term is behind the deactivation requests they may have.

Any thoughts?

sohkai commented

We must make jurors to heartbeat the court when they are trying to withdraw and court term is behind the deactivation requests they may have.

I think this is the happy path we should aim for. With the multi-step transaction experience (soon TM), we should start checking the needed term against all actions we're trying to do.

For example, this is my ideal experience in these scenarios:

  • If the user wants to activate / deactivate, and the court is within within the last term
    • Single transaction; same as now
  • If the user wants to activate / deactivate, and the court is more than one term old
    • Two transactions; we make them do heartbeat (hopefully not too many) and then activate / deactivate
  • If the user wants to withdraw, and the court is current
    • Single transaction; same as now
  • If the user wants to withdraw, and the court is not current
    • Two transactions; we make them do heartbeat and then withdraw

The actions that attempt to ensure the current term

What about all the other actions, like drafting, creating disputes, settling, appealing, etc? Are all of those term agnostic or do they all also update the term if needed?

now we expose the current term as the current term from the court contract itself instead of the current term that it's supposed to be assuming that the court has transitioned.

Does this mean we can replace all the useNow()s with a useCourtNow() (or similar)?

  • 👍1
fabriziovigevani commented

What about all the other actions, like drafting, creating disputes, settling, appealing, etc? Are all of those term agnostic or do they all also update the term if needed?

  • Drafting: Requires court synced

  • Commit, Reveal, Appeal, Confirm Appeal, ExecuteRuling: Could be 1 term behind (tries to ensure the current term)

  • Rewards module actions are term agnostic

Does this mean we can replace all the useNow()s with a useCourtNow() (or similar)?

Yep, we can probably do that, we already have it as a TODO see:

court-dashboard/src/hooks/useDisputes.js

Line 67 in 57a4000

const now = useNow() // TODO: use court clock

My preference would be to have first the multi tx signer and then refactor this logic to react relative to the current term.

  • 👍1
sohkai commented

Thanks for the update!

As this is currently mitigated, we will close this issue and wait until we have the multi-transaction experience to fully solve these heartbeat issues by detecting when we need to force the user into triggering it.