Signup returns 500 when two requests use the same email at the same time

[w-rahul]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the documentation, with the integrated search.
• I already searched in Google "How to X" and didn't find any information.
• I already read and followed all the tutorials in the docs and didn't find an answer.

Example Code

import threading
import uuid

import httpx

data = {
    "email": f"{uuid.uuid4().hex}@example.com",
    "password": "changethis123",
    "full_name": "Race",
}


def signup() -> None:
    r = httpx.post("http://localhost:8000/api/v1/users/signup", json=data)
    print(r.status_code)


threads = [threading.Thread(target=signup) for _ in range(2)]
for t in threads:
    t.start()
for t in threads:
    t.join()
# Expected: 200 and 400. When the two requests overlap: 200 and 500.

Description

Two signup requests with the same email at the same moment: one returns 200 and the other returns 500. One after the other they return 200 and 400. The same happens on POST /api/v1/users/.

Both requests pass the email check before either one inserts. The unique index on user.email stops the second insert, and that error is not handled. No duplicate user is created.

I have a small fix with two tests in #2527, and all checks passed there. Sorry for opening the PR before a discussion. Would you like me to reopen it?

This may also explain #1400, where a 500 on signup with an existing email could not be reproduced

Operating System

Windows

Operating System Details

No response

Project Version

master at aabb901

Python Version

3.14

Additional Context

I found this with racetrap, a tool I am building that forces the order of SQL statements between two requests: https://github.com/w-rahul/racetrap
The script above depends on timing. racetrap forces the order every time.
To be upfront, I used an AI assistant (Claude) to help write the fix and this report. I ran the tool and the tests myself.

[w-rahul]

#2527

[Ramonspe]

Hi!

Your analysis matches the code on master (aabb901). It is a check-then-insert race, and the database is the only thing that stops the duplicate.

• POST /users/signup calls crud.get_user_by_email() and then crud.create_user(), with nothing between them that serializes the two requests (users.py#L146-L159). POST /users/ does the same (users.py#L54-L78).
• The real guard is the unique index: email is declared with unique=True (models.py#L14) and the initial migration creates ix_user_email as unique (e2412789c190_initialize_models.py#L33).
• crud.create_user() commits directly, so the second request gets a sqlalchemy.exc.IntegrityError from session.commit(). Nothing catches it, so FastAPI answers 500. No duplicate row is written, as you saw.

Catching IntegrityError, rolling back and returning the same 400 as the pre-check (what #2527 does) is the usual way to handle this. The pre-check still gives the normal error message in the common case, and the except covers the window between check and insert.

One thing #2527 does not cover: the two update endpoints have the same pattern for email changes. PATCH /users/me (users.py#L81-L100) and PATCH /users/{user_id} (users.py#L182-L211) check get_user_by_email() and then commit. Two concurrent requests that set the same new email (or a signup racing an email change) hit the same unique index and also return 500 instead of 409. The same fix applies there, keeping their 409:

from sqlalchemy.exc import IntegrityError

# PATCH /users/me
user_data = user_in.model_dump(exclude_unset=True)
current_user.sqlmodel_update(user_data)
session.add(current_user)
try:
    session.commit()
except IntegrityError:
    session.rollback()
    raise HTTPException(status_code=409, detail="User with this email already exists")
session.refresh(current_user)
return current_user

For PATCH /users/{user_id} the commit happens inside crud.update_user(), so the try/except goes around that call.

About reopening #2527: that is the maintainers' call. Per the contribution rules quoted when it was closed, the PR is opened (or reopened) once a team member asks for it in this discussion, so linking it here as you did is the expected step.

Hope this helps!