[BUG] Inconsistent Display of Delegated Voting Power on 'Abstain' or 'No Confidence' Votes"

[kneerose]

Context & versions

• When I, as a registered DRep with delegated voting power, attempt to delegate my own vote to "Abstain" or "No Confidence," the card initially displays voting power after the transaction. However, within a few seconds, the delegated power value changes.

Steps to reproduce

• Register as a direct voter.
• Delegate your vote to "Abstain" or "No Confidence."
• Observe the card displaying the message: "You have delegated A123 to 'Abstain'"

Actual behaviour

• The card consistently displays the delegated voting power after the transaction, reflecting the intended selection.

• After a few seconds, the voting power is modified, and the preview reflects the intended selection.

[pmbinapps]

There is such update @MSzalowski @Sworzen1. Looks like the voting power is more update after this change.

[MSzalowski]

It might be cause by the recalculation of the voting power on the chain. On frontend we display that value directly from the backend (without any parsing on the FE side). And that value on the backend is taken directly from DB-sync.

That might not be the issue that we on the govtool side are able to handle, but please @jankun4 could you have a look if there is some part missing?

[jankun4]

The delegated amount is strictly related to the amount of Ada at the user's wallet. Each transaction (including delegating to Abstain) requires paying transaction fee which in turn lowers user's ada-holder voting power a bit.

[kneerose]

@MSzalowski any update on this ?

[MSzalowski]

As I previously and @jankun4 in a recent comment describe - the voting power is calculated directly by db-sync and we don't have any logic around this.

The difference between these values is because of fee (as @jankun4 described) and the reason why it is not displayed right after the transaction is that at this moment the value isn't calculated.

I think that we could close this issue as GovTool has nothing to do around this topic.

What do you think @kneerose ?

[spannercode]

@kneerose and I just had a discussion about this issue. Because of the occasional mismatch in voting power, the tests has become flaky for us. We can understand the reasoning that this value is coming from DbSync. But from the user perspective, this difference could be confusing, and should be addressed. (Maybe an update the copy that the value shown could be slightly different).

We can close the issue here as issue caused by the dependency, however, we recommend that this should be fixed, be it in the DbSync. We can wait until the next release of DbSync and retest it again. If the issue exists, then I think we should create an issue on DbSync repo so devs there can debug and fix the issue.

[Ryun1]

I believe this issue is because;

• GovTool is showing the incorrect delegation value before the transaction is finalised on-chain
• So when DBSync updates the voting power based on latest transaction then the voting power is updated
• this is causing flakiness in tests

This is a tricky one, because at any time a wallet's voting power may change
The user may send or receive ada at any time (regardless of GovTool)
So I feel it would be the right thing to extra logic to Govtool to preempt the cost of transaction fees

@kneerose can you point me to the test case that this is effecting please
for me, it might make more sense to change the testcase rather than anything else

[kneerose]

@Ryun1

This is the Allure report. You can view the history for tests 2U and 2V there to check for flakiness. Additionally, see the overview to understand how each test works step by step.

[MSzalowski]

So I feel it would be the right thing to extra logic to Govtool to preempt the cost of transaction fees

Can we expect a scenario in which the value calculated by GovTool will differ from the final value anyway? Even if we know all the values needed for such a calculation, can we guarantee that these values will not vary?

@Ryun1 I wouldn't go for the solution where some of the voting powers (or some other ADA values) are taken from db-sync (calculated there) and some others are calculated by GovTool at least, not as a solution for flaky tests. We should have single source of truth that emits events if values changes

[Ryun1]

oops! I wrote the opposite of what I meant

So I feel it would NOT be the right thing to extra logic to Govtool to preempt the cost of transaction fees

[bosko-m]

@MSzalowski @Ryun1 Do we have an understanding of whats needed here?

[bosko-m]

@kneerose @MSzalowski @Ryun1 Can we close this one?