Repository navigation
Advancing a round counts open and cancelled votes, unlike the results preview #638
Description
The entries that advance to the next round can differ from what the results preview shows: advancing counts every vote that has a value, including open tasks and cancelled votes, while the preview counts only completed votes.
Reproduce (montage-dev, 2026-10-02)
After the requalify case above (a reopened task that still holds its old value 1.0): the preview showed 1 entry at threshold 1.0, advancing at 1.0 took 2. The extra entry is the one whose vote had been reopened.
Cause [confirmed in the code]
get_rating_advancing_group() averages Vote.value over all votes of an entry, with no status filter. get_round_average_rating_map() (the preview) filters on status = 'completed'. The same average also counts a juror twice when they voted on both copies of a duplicated task (#334).
Expected
Advance on completed votes only, and per juror at most once, so the preview and the advance agree.
Written with Claude (Claude Code) on behalf of @lgelauff.
Activity
JyantiM commentedon Oct 16, 2026
Hi @lgelauff! I'd like to work on this issue.
After looking at the code and the git history, I can see that part of this has already been fixed. Specifically, get_rating_advancing_group() now filters on Vote.status == COMPLETED_STATUS (added in commit 0c7e33d as part of the quorum-reduction PR #617), so the advance and preview should now agree in the normal case.
However, the bug can still reproduce through the disqualify - requalify flow. The requalify() function resets all votes on an entry back to active, including ones that were already completed before the disqualification. This means a juror's finished vote effectively disappears from the results, and the advance/preview disagree again.
The fix I'm planning: in requalify(), only reopen votes that were cancelled and leave completed votes untouched.
If this aligns with the intended direction, I'd love to be assigned to this.