Concurrent duplicate signups crash instead of returning a clean error

A slow network, a double-click on "Sign Up," or a mobile client's automatic retry-on-timeout can all cause two near-simultaneous POST /api/auth/register requests for the same email to reach the server at almost the same instant. Right now, when that happens, one of the two requests doesn't get a clean "that email is already taken" -- it crashes with an unhandled database error. In production that surfaces as a generic, unhelpful 500 internal_error instead of the 409 email_taken the client actually needs to show the user "looks like you already have an account -- try logging in instead." Worse, every one of these races becomes noise in error tracking / on-call alerting for something that is not actually a system failure -- it's an entirely predictable, expected interaction that the code simply doesn't handle.

register() checks whether the email is taken, and only then commits a new User row: it raises 409 email_taken if User.query.filter_by(email=email).first() is not None, otherwise it builds the user, sets the password, and calls db.session.commit(). This is a classic time-of-check-to-time-of-use (TOCTOU) race: if two requests for the same email both run the SELECT before either one's INSERT commits, both pass the "not taken" check. The first commit() succeeds. The second commit() violates the database's UNIQUE constraint on users.email and raises sqlalchemy.exc.IntegrityError -- which nothing in register() catches.

cd flask/movie_watchlist .venv/bin/python -m pytest practicetickets/test_ticket07_registration_race.py -v

Needs genuine concurrency to trigger -- a sequential curl twice will not show it,

because the first request's commit finishes long before the second one's SELECT

even runs. The dedicated test reproduces it deterministically with two real threads

synchronized on a threading.Barrier so both requests reach the "check" step at the

same time.

The uniqueness pre-check and the write are two separate round-trips to the database with no locking or transaction isolation tying them together -- there's a real window between them where another request can interleave. This is a genuine race condition, not a hypothetical one: it reproduces reliably (5/5 runs in local testing) once two requests are forced to overlap, because Python's normal thread scheduling gives ample opportunity to interleave between the SELECT and the commit() -- especially since password hashing (scrypt) in between takes real wall-clock time.

The pre-check (if User.query.filter_by(...).first() is not None) is still worth keeping -- it's the fast path that avoids even attempting a write for the common case, and it keeps the error message specific. What's missing is handling the case where the pre-check says "clear," but the database disagrees by the time the commit actually happens. Look at what db.session.commit() raises when the underlying INSERT violates a UNIQUE constraint (the test's failure message will show you the exact exception type), and how the rest of this codebase -- see app/blueprints/movies/omdb_client.py's cache-insert try/except for a pattern already in the codebase -- reacts to a commit that might fail for a reason outside its control. You'll also need db.session.rollback() before you can safely use the session again after a failed commit.