Results endpoint reports the option count as the vote count

Nobody has started this yet — be first.

Business impact

GET /api/polls/{id}/results/ is the one endpoint whose entire job is to report accurate numbers -- it's what a poll creator screenshots, what gets shown live on a results page, and what any downstream reporting would be built on. Right now total_votes is wrong (it reports how many options the poll has, not how many votes were cast), which cascades into every option's percentage also being wrong -- sometimes reporting over 100% for a single option, which is an immediate, visible sign to any user that the numbers on screen cannot be trusted. For a poll/voting product, "the results are wrong" is about as core a trust failure as there is.

Problem

PollViewSet.results annotates each option with its own vote_count correctly (via Count("votes")), but then computes the poll-wide total_votes as the number of options on the poll instead of the sum of all votes cast across those options.

Current behavior

GET /api/polls/{id}/results/ reports a total_votes equal to the number of options on the poll, not the number of votes actually cast -- which can push individual option percentages above 100%.

Expected behavior

total_votes equals the total number of Vote rows for the poll (the sum of every option's vote_count), and each option's percentage is vote_count / total_votes * 100 against that correct total.

Steps to reproduce

cd django/poll_app source .venv/bin/activate python manage.py runserver &

curl -s -X POST http://127.0.0.1:8000/api/auth/register/ -H "Content-Type: application/json"
-d '{"username":"dave","email":"dave@example.com","password":"d-strong-password-1"}'

-> save TOKEN_DAVE

curl -s -X POST http://127.0.0.1:8000/api/polls/ -H "Authorization: Token $TOKEN_DAVE" -H "Content-Type: application/json" -d '{"question":"Best editor?","options":["vim","emacs"]}'

Why this matters

This is already covered by two pre-existing tests in polls/tests/test_api.py (test_results_aggregation_counts_and_percentages and test_results_with_zero_votes_does_not_divide_by_zero), both of which currently fail because of it -- the zero-votes test happens to still see 0.0 percentages (0 divided by anything nonzero is still 0), but its total_votes assertion catches the miscount directly.

Suggested approach

Look at how total is computed in PollViewSet.results in polls/views.py, right next to the line that builds options via annotate(vote_count=Count("votes")). Each option in that list already carries its own correct vote_count -- think about what collection total should actually be reducing over.

Acceptance criteria

total_votes equals the sum of every option's vote_count, not the number of options.
Every option's percentage is computed against that corrected total and never exceeds 100%.
The zero-votes case still reports total_votes: 0 and every percentage: 0.0 (no division by zero).
polls/tests/test_api.py passes in full again.

Verification

.venv/bin/python manage.py test practicetickets.test_ticket03_results_total_votes_miscounted -v 2 && .venv/bin/python manage.py test polls.tests.test_api.PollAPITests.test_results_aggregation_counts_and_percentages polls.tests.test_api.PollAPITests.test_results_with_zero_votes_does_not_divide_by_zero -v 2

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/results-total-votes-miscounted

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/results-total-votes-miscounted

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Poll App — Django REST Polls with a Race-Proof Vote

A Django + DRF poll/voting API demonstrating that "one vote per user per poll" only actually holds under concurrency when it is enforced by a database constraint, not an application-level check -- with a curated set of bugs and gaps layered on top of a real, tested authorization and results-aggregation surface.

Fork on GitHub

Download

Setup

Poll App — Django REST Polls with a Race-Proof Vote

cd django/poll_app
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

python manage.py migrate
python manage.py createsuperuser   # for /admin/, not required for the API
python manage.py runserver

This runs against sqlite by default. The API is at , admin at . Copy to to override defaults (, , , ) -- optional for sqlite + local dev, required for Docker. Running always forces Celery into eager (synchronous) mode, so no Redis/worker is needed to run the test suite or the practice tickets.

Results endpoint reports the option count as the vote count

-> save TOKEN_DAVE

Stuck on something?

Poll App — Django REST Polls with a Race-Proof Vote

-> {"id": 1, "options": [{"id": 1, "text": "vim"}, {"id": 2, "text": "emacs"}], ...}

Register and cast 3 votes for "vim" and 2 for "emacs" (5 distinct voters --

a script or five separate signups), then:

-> {"total_votes": 2, "options": [

{"id": 1, "text": "vim", "vote_count": 3, "percentage": 150.0},

{"id": 2, "text": "emacs", "vote_count": 2, "percentage": 100.0}]}

total_votes should be 5 (3 + 2), and a percentage over 100% is an

immediate sign something is off.