Overlapping status-change requests can silently corrupt an application's history

StatusChange is the tracker's permanent record of what happened to an application and when -- the entire value proposition of this app over a spreadsheet is "I can trust this history." apply_transition is the single code path every status change goes through specifically to guarantee that trust. But it was never hardened against two requests landing close together (a user double-clicking "reject," two browser tabs open on the same application, a retried request after a slow network) -- and when that happens, the slower request can silently overwrite a status that a faster, later, perfectly legitimate request already committed, while also permanently writing a StatusChange record describing a transition that never should have been allowed to happen. A user could end up with an application that says interview when they distinctly remember rejecting it -- and a history log that "proves" an impossible sequence of events, with no error, no warning, and nothing to grep for afterward.

apply_transition() reads from_status = self.status once, at the top of the method, which is whatever status was loaded into this Python object whenever it was fetched -- not the row's actual current status in the database at the moment this method runs. If two independently-fetched in-memory copies of the same Application race, the second one can validate and persist a now-illegal transition against a stale in-memory status, silently clobbering whatever the first one already committed.

The ticket test simulates the race deterministically with two independently-fetched

in-memory copies of the same row, rather than real threads:

app_copy_1 = Application.objects.get(pk=app.pk) app_copy_2 = Application.objects.get(pk=app.pk) app_copy_1.apply_transition(Application.STATUS_REJECTED) # commits first, succeeds app_copy_2.apply_transition(Application.STATUS_INTERVIEW) # stale self.status == 'applied'

-> currently succeeds and clobbers "rejected" with "interview" -- should raise ValueError

This is a classic check-then-act (time-of-check to time-of-use) race, the same class of bug that causes lost updates in any system where "read, decide, write" isn't atomic against concurrent writers. The fix isn't about threads or timing tricks -- it's about what data the validation check reads from: an in-memory attribute that can go stale the instant another writer commits, versus the row's actual current state at write time.

Look at how apply_transition currently reads self.status up front and never touches the database again until its own .save(...) at the very end. Consider what it would mean to re-fetch (or lock) the row immediately before validating and writing, inside a single atomic operation -- Django's transaction.atomic() and QuerySet.select_for_update() are the relevant tools here, though the exact mechanism is your call as long as a later-arriving stale transition is rejected rather than silently applied.