Closing a poll doesn't stop votes already in flight

A poll creator (or a moderator) deactivates a poll expecting that to immediately stop new votes -- that's the entire point of is_active, and it's how a live prediction market gets finalized, how a moderator takes down a poll that's being abused, or how an interview panel closes scoring before tallying results. Right now, a vote that was already "in flight" (its Poll object was fetched by the web process a moment earlier, before the deactivation happened) can still be recorded after the poll was closed, because the code checking "is this poll open?" never looks at the database again once it has that Python object in hand. To anyone watching the results, this looks like the deactivation silently didn't work -- a vote appears on a poll that's supposed to be closed, with no error, no log entry a normal admin would notice, nothing to point at.

cast_vote(user, poll, option) in polls/services.py checks poll.is_active on the Poll object it was handed. PollViewSet.vote() fetches that object once, near the start of the request, via self.get_object(). Everything between that fetch and the cast_vote() call (serializer validation, looking up the chosen Option, etc.) is real, non-zero time during which a different request can run PollViewSet.update() and flip is_active to False in the database. The first request's poll object never observes that change -- its is_active attribute is still whatever it was read as when the object was fetched -- so cast_vote happily proceeds to record the vote.

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

from django.contrib.auth import get_user_model from polls.models import Option, Poll from polls.services import cast_vote

User = get_user_model() creator = User.objects.create_user(username="creator", password="x") voter = User.objects.create_user(username="voter", password="x") poll = Poll.objects.create(question="Best editor?", created_by=creator) option = Option.objects.create(poll=poll, text="vim")

Fetch a fresh, active Poll object -- exactly what PollViewSet.vote()

does at the start of a request.

poll = Poll.objects.get(pk=poll.pk)

Simulate a second, concurrent request deactivating the poll via a

different code path (the same one PollViewSet.update() uses) -- this

This is the "hard" ticket in this set for the same reason test_race.py's duplicate-vote scenario is the app's headline lesson: a check performed against application-held state, rather than the database at write time, cannot be trusted once concurrent requests are possible. The difference here is that the fix for the duplicate-vote case (a UniqueConstraint + catching IntegrityError) doesn't transfer directly -- is_active isn't a uniqueness constraint, so closing this hole needs a different technique: re-reading (and ideally locking) the poll's current state as part of the same write, not relying on a constraint to reject the impossible after the fact.

Think about what "read the current state, as of right now, as part of the write" means for a single row you're about to insert against -- this is exactly the kind of situation select_for_update() (inside transaction.atomic(), which cast_vote already uses for the Vote insert) exists for: it re-fetches a row from the database, locking it so no concurrent transaction can change it out from under you until you're done. Compare that to just re-querying Poll.objects.get(pk=poll.pk) without a lock, and think about whether that alone actually closes the window or just narrows it.