Lauro Gripa
924089ff33
This PR fixes a bug in the tally accrual of approvals/rejections for
Candidates and Defender. The issue happened because:
- The `match maybe_old` is reducing `weight` from the tally:
```
Some(Vote { approve: true, weight }) => tally.approvals.saturating_reduce(weight),
Some(Vote { approve: false, weight }) => tally.rejections.saturating_reduce(weight),
```
- But `match approval` is accruing only `1` to the tally:
```
true => tally.approvals.saturating_accrue(1),
false => tally.rejections.saturating_accrue(1),
```
This way, if a member is rank 1 his vote is going to have weight 1 when
accruing but weight 4 when reducing from the tally. For example, let's
say:
- There's a Candidate with 0 approvals and 12 rejections;
- A ranked Member votes against the Candidate;
- The tally changes to 0 approvals and 13 rejections (should be 16);
- The Member changes his vote to an approval;
- Now tally changes to 1 approvals and 9 rejections, removing the
accrued approvals from other Members;
- If the Member keeps changing his vote, it wipes the tally clean.
So this PR changes `match approval` to accrue `weight` instead of just
`1` and changes the tests:
- Fixes `challenges_work`. This test started failing after the fix. The
reason is that the test assumes that all Members have equal weights to
their votes, but Member 10 is ranked, so his vote should have weight 4
against the Defender. So instead of using Member 10, I added Member 50
of rank 0 to keep the same logic;
- Improves `votes_are_working`. Added some assertions to check if the
tally is correct even after a ranked Member changes his vote a couple
times;
- Fixes `waive_repay_works`. Unrelated to the bug, but this test was
yielding a false positive. The test is ranking up Member 20, but
asserting the rank of Member 10, which is already ranked up.
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: command-bot <>
NOTE: We have recently made significant changes to our repository structure. In order to streamline our development process and foster better contributions, we have merged three separate repositories Cumulus, Substrate and Polkadot into this repository. Read more about the changes here.
Polkadot SDK
The Polkadot SDK repository provides all the resources needed to start building on the Polkadot network, a multi-chain blockchain platform that enables different blockchains to interoperate and share information in a secure and scalable way. The Polkadot SDK comprises three main pieces of software:
Polkadot
Implementation of a node for the https://polkadot.network in Rust, using the Substrate framework. This directory
currently contains runtimes for the Polkadot, Kusama, Westend, and Rococo networks. In the future, these will be
relocated to the runtimes repository.
Substrate
Substrate is the primary blockchain SDK used by developers to create the parachains that make up the Polkadot network. Additionally, it allows for the development of self-sovereign blockchains that operate completely independently of Polkadot.
Cumulus
Cumulus is a set of tools for writing Substrate-based Polkadot parachains.
Upstream Dependencies
Below are the primary upstream dependencies utilized in this project:
Security
The security policy and procedures can be found in docs/contributor/SECURITY.md.
Contributing & Code of Conduct
Ensure you follow our contribution guidelines. In every interaction and contribution, this project adheres to the Contributor Covenant Code of Conduct.
Additional Resources
- For monitoring upcoming changes and current proposals related to the technical implementation of the Polkadot network,
visit the
Requests for Comment (RFC)repository. While it's maintained by the Polkadot Fellowship, the RFC process welcomes contributions from everyone.