DEV Community: Majid Khazaei

The Second Race Condition: When Updating a Record Is Just as Dangerous as Creating One

Majid Khazaei — Wed, 23 Sep 2026 15:17:11 +0000

A Django concurrency story about read-then-mutate, silent no-ops, and why one fix is never enough.

Section 1: The Bug That Didn't Announce Itself

After I fixed the add_member race condition, I did what most developers do after a win: I closed the ticket and moved on.

Then a small voice asked a very inconvenient question:

If add_member had a race condition, what about change_member_role?

That question turned into an audit. And the audit turned into two more bugs.

Here's the thing about race conditions: they don't travel alone. When you find one check-then-act pattern, you're not looking at an isolated mistake — you're looking at a category. The same developer (me) wrote similar code in similar places, and the same class of bug is hiding in all of them.

I pulled up every mutation in my WorkspaceService:

WorkspaceService
├── create                → atomic ✅
├── add_member            → fixed in previous article ✅
├── change_member_role    → ? ← here
├── remove_member         → ? ← and here
├── transfer_ownership    → select_for_update ✅
└── delete                → atomic ✅

Two methods stood out immediately.

@staticmethod
def change_member_role(*, workspace, user, role, actor):
    with transaction.atomic():
        membership = Membership.objects.get(workspace=workspace, user=user)  # ← no lock!
        # ...
        membership.role = role
        membership.save()
        NotificationService.create(...)
        return membership

@staticmethod
def remove_member(*, workspace, user, actor):
    with transaction.atomic():
        membership = Membership.objects.get(workspace=workspace, user=user)  # ← no lock!
        # ...
        membership.delete()
        return True

No lock. No select_for_update. Just a plain get(), a mutation, and a save.

I had a suspicion. But suspicion isn't proof. So I wrote tests.

Section 2: The Contracts That Came Before the Tests

Before I could write a test, I had to decide what correct behavior even meant. This is where the second bug started teaching me things the first one hadn't.

There's a subtle trap in concurrency testing: if you don't define the contract precisely, you'll end up asserting on things that are inherently non-deterministic. So I wrote three contracts — one strict, one loose, one clever.

Contract 1: Same-Role Concurrent Change

B = MEMBER

Thread 1 (admin_a): B → ADMIN
Thread 2 (admin_c): B → ADMIN

Expected:

✅ Both operations succeed (the second is a no-op)
✅ Exactly one membership
✅ Final role = ADMIN
✅ Exactly one WORKSPACE_ROLE_CHANGED notification
✅ No IntegrityError

Key insight: this contract is different from add_member's contract.

For add_member, a duplicate is an error (400). For change_member_role, the same role is a no-op (200).

Why? Because the semantics are different:

add_member(B) again
    → B really doesn't want to join twice
    → conflict → 400

change_member_role(B, ADMIN) again
    → B is already ADMIN
    → desired state achieved
    → no-op → 200

This distinction is not cosmetic. It changes what you assert on, and — as we'll see — it changes how you catch the bug.

Contract 2: Different-Role Concurrent Change

Thread 1: B (MEMBER) → ADMIN
Thread 2: B (MEMBER) → MEMBER

Expected:

⚠️ Winner is non-deterministic
✅ Exactly one membership
✅ Final role ∈ {MEMBER, ADMIN}
✅ No IntegrityError

Here I couldn't assert on the final role — transaction ordering isn't deterministic. This is an exploration test, not a strict contract. It exists to catch invariant violations, not to enforce a specific outcome.

Contract 3: Role Change + Remove

Thread 1: B → ADMIN
Thread 2: remove(B)

Expected:

✅ Final count = 0 (in either ordering)
✅ No IntegrityError

Why count = 0?

If role change commits first → B is ADMIN → owner can still remove an admin → count = 0
If remove commits first → role change hits DoesNotExist → count = 0

Both orderings converge. That's the mark of a good concurrency test — it holds regardless of which thread wins.

Section 3: The First RED — A Duplicate Notification

I wrote the same-thread setup I'd used before: two real threads, a threading.Barrier(2), real transactions, and connection.close() in a finally.

@pytest.mark.django_db(transaction=True)
def test_concurrent_same_role_change(self):
    workspace, owner, admin_a, admin_c, target = self._setup()

    def change_a():
        return WorkspaceService.change_member_role(
            workspace=workspace, user=target,
            role=MembershipRole.ADMIN, actor=admin_a,
        )

    def change_c():
        return WorkspaceService.change_member_role(
            workspace=workspace, user=target,
            role=MembershipRole.ADMIN, actor=admin_c,
        )

    successes, errors = self._run_concurrent(change_a, change_c)

    assert len(successes) == 2
    assert len(errors) == 0

    memberships = Membership.objects.filter(workspace=workspace, user=target)
    assert memberships.count() == 1
    assert memberships.first().role == MembershipRole.ADMIN

    role_notifs = Notification.objects.filter(
        type=Notification.Type.WORKSPACE_ROLE_CHANGED,
    )
    assert role_notifs.count() == 1

It failed. But not on the assertion I expected.

FAILED
AssertionError: Expected exactly 1 role-change notification, got 2

The membership count was correct. The final role was correct. The database hadn't corrupted anything.

What had gone wrong was invisible to the database.

Here's the timeline:

Thread A                    Thread B
   │                           │
   ├─ get() → MEMBER           │
   │  (no lock)                ├─ get() → MEMBER
   │                           │  (no lock)
   ├─ role = ADMIN             │
   ├─ save()                   ├─ role = ADMIN
   ├─ NotificationService      ├─ save()
   │  .create()                │
   │  → notif #1               ├─ NotificationService
   │                           │  .create()
   ├─ commit                   │  → notif #2
   │                           │
   │                           ├─ commit
   └──                         └──

Both threads read MEMBER before either one committed. Both saw a real transition. Both wrote a notification.

From the database's perspective, everything is fine. From the user's perspective, they just got two notifications for one role change.

This is the same class of bug as check-then-create, but wearing a different mask:

# Anti-pattern #1 (previous article):
check() → create()

# Anti-pattern #2 (this article):
read() → mutate() → save()

Different shape. Same underlying flaw: a window between decision and action that isn't protected against concurrent access.

Section 4: The Fix — One Line

The right pattern already existed in the codebase. transfer_ownership was using it:

actor_membership = Membership.objects.select_for_update().get(...)
new_owner_membership = Membership.objects.select_for_update().get(...)

So the fix was a single line per method:

# Before
membership = Membership.objects.get(workspace=workspace, user=user)

# After
membership = (
    Membership.objects
    .select_for_update()
    .get(workspace=workspace, user=user)
)

Why does this work?

select_for_update in PostgreSQL takes a row-level exclusive lock. While Thread A holds it, Thread B waits. When Thread A commits and releases the lock, PostgreSQL hands Thread B the new version of the row — not a stale snapshot.

So:

Thread A                    Thread B
   │                           │
   ├─ SELECT FOR UPDATE        │
   │  → lock acquired          │
   │  → MEMBER read            ├─ SELECT FOR UPDATE
   │                           │  → waiting for lock
   ├─ role = ADMIN             │
   ├─ save()                   │
   ├─ NotificationService      │
   │  .create() → notif #1     │
   ├─ commit                   │
   │  → lock released          │
   │                           ├─ lock acquired
   │                           ├─ re-read → ADMIN
   │                           ├─ role == ADMIN
   │                           │  → return (no-op)
   │                           ├─ commit
   └──                         └──

The check if membership.role == role: return membership was already in the code — it had just never been able to do its job because both threads were reading stale data.

One line. One fix. One bug gone.

Section 5: The Second Bug — A Silent No-Op

The remove_member method had the same problem. But it had an additional twist that I hadn't anticipated.

Consider this scenario:

Thread A (change): read(B) → B=MEMBER
Thread B (remove): read(B) → delete(B) → commit
Thread A: B.role = ADMIN → save()

What does save() do when the row no longer exists?

The answer surprised me: nothing. Django sends an UPDATE ... WHERE id = ..., and the database matches zero rows. No error is raised. Silent no-op.

But the code continues:

membership.role = role
membership.save()                    # silent no-op
NotificationService.create(...)      # ❌ notification created

Result: a WORKSPACE_ROLE_CHANGED notification for a role change that never actually happened.

This is worse than the duplicate-notification bug. In the duplicate case, at least something real happened. Here, the entire event is a ghost — a notification with no corresponding state change.

The fix was the same: add select_for_update. Now Thread A waits for Thread B to commit, and then hits DoesNotExist — a loud, visible failure instead of a silent one.

with transaction.atomic():
    membership = (
        Membership.objects
        .select_for_update()
        .get(workspace=workspace, user=user)
    )

Two methods. Two bugs. Two lines.

Section 6: The Third Test — A Test Almost Broke

The contract for role-change + remove looked simple:

Thread 1: B → ADMIN
Thread 2: remove(B)
Count should be 0 in either ordering.

But it almost wasn't order-independent. Here's what I got wrong first:

I initially wrote the test using an admin to perform the removal.

Ordering 1:
  A: B → ADMIN
  C: remove(B) as ADMIN
  → "Admin cannot remove another admin"
  → count = 1 ❌

Ordering 2:
  C: remove(B) as ADMIN
  → ok
  A: B → DoesNotExist
  → count = 0 ✅

That's order-dependent — the test would pass or fail depending on which thread won. Useless.

The fix was to change the actor to the owner:

Ordering 1:
  A: B → ADMIN
  Owner: remove(B)
  → owner can remove admin → count = 0 ✅

Ordering 2:
  Owner: remove(B)
  → ok
  A: B → DoesNotExist → count = 0 ✅

Now the test is order-independent. It holds no matter which thread commits first.

The lesson: in concurrency tests, choose roles that make the test order-independent. If you can't, you're not testing an invariant — you're testing a coin flip.

Section 7: One More Consideration — Deadlock Potential

Once I decided to add select_for_update, a new question surfaced: can this create deadlocks?

Deadlocks happen when two transactions try to lock the same set of rows in different orders:

Thread A: lock(X) → lock(Y) → ...
Thread B: lock(Y) → lock(X) → ...   ← deadlock

So I checked my remove_member implementation carefully:

# target: locked
membership = Membership.objects.select_for_update().get(...)

# actor: NOT locked (plain read)
actor_membership = Membership.objects.get(...)

Only one row gets locked — the target membership. The actor's membership is read without a lock.

That means no thread can ever hold two locks in a conflicting order. Deadlock is impossible by construction.

Had I locked the actor as well — which is a natural thing to want to do — I would have opened the door to deadlocks in multi-step operations.

The principle: lock the minimum set of rows required, and lock them in a consistent order. More locks ≠ safer. More locks = more chances to deadlock.

Section 8: Five Lessons From the Second Bug

This second round of bug-hunting taught me things the first one couldn't.

1. `check-then-act` isn't the only race-prone pattern

The first article was about check-then-create. This one is about read-then-mutate. The shapes are different, but the underlying flaw is the same:

Any operation with a read followed by a write, without a lock, is race-prone.

The fix isn't "add another check." The fix is either a lock or an atomic database operation. There is no third option.

2. Silent no-ops are more dangerous than loud failures

When save() hits a deleted row, Django doesn't raise. It sends an UPDATE matching zero rows and moves on.

If your code continues past that point — sending a notification, updating a counter, logging an event — you've now built a system that creates side effects for events that never happened.

The only way to catch this class of bug is a concurrency test with realistic ordering.

3. In concurrency tests, choose roles that make the test order-independent

If a test passes in one ordering and fails in another, it's not testing an invariant — it's testing the scheduler. Rewrite the test so the assertion holds regardless of which thread wins. If you can't, the contract isn't fully specified yet.

4. Lock only what you need — and always in the same order

select_for_update on every row you touch seems safe. It isn't. It increases the chance of deadlocks and reduces concurrency for no benefit.

Lock the rows you actually mutate. Read the rest without locking. When you must lock multiple rows, lock them in a consistent order across the codebase.

5. A consistent pattern is worth more than a clever fix

After this chapter, every membership mutation follows the same rule:

WorkspaceService
├── add_member            → Nested Atomic + Error Conversion
├── change_member_role    → select_for_update
├── remove_member         → select_for_update
├── transfer_ownership    → select_for_update (already)
└── delete                → atomic

A new developer reading this code sees a pattern. A code reviewer spots deviations in seconds. A future bug surfaces faster because the inconsistency stands out.

Consistency isn't glamorous, but it's what makes a codebase survivable.

Section 9: The Results

After two fixes, the full test suite:

test_concurrent_same_role_change        ✅ PASSED
test_concurrent_different_role_change   ✅ PASSED
test_concurrent_role_change_and_remove  ✅ PASSED

Three tests. Two bugs. Two lines of implementation code.

The commits were kept separate, because tests and fixes are different stories:

# Commit 1: Tests
git commit -m "test(workspace): cover concurrent role change scenarios"

# Commit 2: Implementation
git commit -m "fix(workspace): serialize concurrent membership mutations with row locks"

When a future developer bisects these commits, they'll see: first the test that proves the bug, then the fix that closes it. That's how you write a changelog that teaches.

Final Thought

The first race condition taught me that check-then-create is dangerous.

The second one taught me something harder: race conditions are a category, not an incident.

When you find one, don't patch it and move on. Audit the sibling methods. Look for the same shape under a different name. Assume that if you made the mistake once, you made it — or something close to it — everywhere you wrote similar code.

The two bugs in this chapter were hiding in plain sight. They passed every unit test. They passed every integration test. They passed code review. They looked correct.

And under load — under real load, in real production, with real users hitting the same endpoint from different devices — they would have quietly corrupted the state of the system, one duplicate notification at a time.

The fix was two lines.

The lessons were worth much more.

Majid Khazaei is a backend engineer specializing in Django, PostgreSQL, and production-grade API design. He writes about concurrency, data integrity, and the engineering discipline behind reliable systems.

🔗 GitHub: https://github.com/majidkhazaei
🔗 LinkedIn: https://www.linkedin.com/in/majid-khazaei-dev

#django, #python, #concurrency, #backend, #postgresql, #testing

The Concurrency Bug That Only Appears Under Load: A Django Race Condition Story

Majid Khazaei — Sat, 19 Sep 2026 14:44:53 +0000

Section 1: The Bug That Never Shows Up in Development

There's a category of bugs that haunts every backend engineer: the ones that pass every test you write, work perfectly on your laptop, and then — one day — silently break in production.

I found one of those bugs last week. Not in a library, not in a framework. In my own code.

It started with a simple feature: a user adds another user to a workspace. The service layer looked clean:

with transaction.atomic():
    if Membership.objects.filter(workspace=workspace, user=user).exists():
        raise ValueError(f"User {user} is already a member of workspace {workspace.name}")

    membership = Membership.objects.create(
        workspace=workspace,
        user=user,
        role=MembershipRole.MEMBER,
    )

    NotificationService.create(
        recipient=user,
        notification_type=Notification.Type.WORKSPACE_JOINED,
        actor=actor,
        workspace=workspace,
    )
    return membership

Read it once. Read it twice. It looks correct. There's a check, there's an insert, there's a notification. All inside an atomic block. What could possibly go wrong?

That pattern — check-then-create — is one of the most natural things a developer can write. And it has a flaw that only reveals itself when two requests arrive at the exact same time.

I wrote a concurrency test to prove the code was safe. Instead, the test proved it wasn't.

Section 2: The Journey — From a Green Test to a Hidden 500

Step 1: Writing the test that would expose everything

To test concurrency properly, I couldn't just call the service twice in a row. Sequential calls aren't concurrency — they're just two isolated operations. I needed two real requests racing against each other.

That meant three things:

Real transactions — not the wrapped ones pytest uses by default
Two independent threads — each with its own database connection
A synchronization barrier — so both threads start their critical section at the same moment

The setup looked like this:

@pytest.mark.django_db(transaction=True)
def test_concurrent_add_member_creates_one_membership_and_one_notification():
    workspace = WorkspaceFactory()
    actor_a = UserFactory()
    actor_b = UserFactory()
    target = UserFactory()

    MembershipFactory(user=actor_a, workspace=workspace, role=MembershipRole.OWNER)
    MembershipFactory(user=actor_b, workspace=workspace, role=MembershipRole.ADMIN)

    barrier = threading.Barrier(2)
    successes = []
    errors = []

    def worker(actor):
        try:
            barrier.wait()  # ← both threads stop here until both arrive
            membership = WorkspaceService.add_member(
                workspace=workspace, user=target, actor=actor,
            )
            successes.append(membership.id)
        except Exception as exc:
            errors.append(exc)
        finally:
            connection.close()

    threads = [
        threading.Thread(target=worker, args=(actor_a,)),
        threading.Thread(target=worker, args=(actor_b,)),
    ]
    for t in threads: t.start()
    for t in threads: t.join()

    assert len(successes) == 1
    assert len(errors) == 1
    assert Membership.objects.filter(workspace=workspace, user=target).count() == 1

The barrier is the key. Without it, one thread always finishes before the other even starts, and you're not testing concurrency — you're testing race conditions that don't exist.

Step 2: When green isn't good enough

The test passed. Two threads, one success, one failure. The final state was correct: exactly one membership, exactly one notification.

But something felt off. I added a diagnostic line to inspect the error:

print(type(errors[0]).__name__)

The output was:

IntegrityError

Not ValueError. IntegrityError.

For those unfamiliar with Django: ValueError is a domain error. You raise it intentionally. It's what a ViewSet catches and converts into a clean 400 Bad Request.

IntegrityError is a database error. It means the SQL layer rejected your query. Left uncaught, it becomes a raw 500 Internal Server Error — the kind of error that pages you at 3 AM and makes users think your product is broken.

The race condition wasn't in the data — the database's UNIQUE constraint had protected the data perfectly. The race was in the error semantics.

Step 3: Understanding the actual race

I traced through the timeline, and it became obvious:

Thread 1: exists()?  → NO
Thread 2: exists()?  → NO       ← both threads pass the check
Thread 1: create()   → ✅ commit
Thread 2: create()   → ❌ IntegrityError

Both threads run inside transaction.atomic(). But PostgreSQL's default isolation level is READ COMMITTED. That means each transaction can only see data that has already been committed by other transactions.

Neither thread has committed when the other runs exists(). So both see "no existing membership" and both proceed to insert.

One wins. One loses. And the loser surfaces a raw database error to the user.

This is the textbook example of why check-then-create is dangerous. And it's exactly the kind of bug that never shows up in development — because nobody clicks "add member" twice in the same millisecond on their laptop.

Step 4: Choosing between three fixes

I considered three approaches:

Option A: get_or_create
Replace the check-then-create with Django's get_or_create:

membership, created = Membership.objects.get_or_create(
    workspace=workspace, user=user,
    defaults={'role': MembershipRole.MEMBER},
)
if not created:
    raise ValueError("already a member")

This looks elegant. It isn't. get_or_create is itself check-then-create underneath — it just hides the pattern behind a helper. Under the same race, both threads can fail the get, both attempt the create, and one still hits IntegrityError. Same bug, more subtly disguised.

Option B: select_for_update
Lock the workspace row before checking:

Workspace.objects.select_for_update().get(pk=workspace.pk)
# then check-then-create

This eliminates the race entirely — but at a cost. Every add_member on the same workspace now serializes behind a database lock. Under real load, that's a throughput bottleneck. Two users adding members to the same workspace would queue behind each other, even though there was never any actual conflict.

Option C: Catch IntegrityError, convert to ValueError
Let the database do its job, then translate its error into a domain error:

try:
    with transaction.atomic():
        membership = Membership.objects.create(
            workspace=workspace, user=user,
            role=MembershipRole.MEMBER,
        )
except IntegrityError as exc:
    raise ValueError(
        f"User {user} is already a member of workspace {workspace.name}"
    ) from exc

This is the option I chose. Here's why.

Step 5: The nested atomic — and why it matters

The natural first attempt is to catch IntegrityError at the outer level:

with transaction.atomic():
    if Membership.objects.filter(...).exists():
        raise ValueError(...)
    try:
        Membership.objects.create(...)   # ← IntegrityError happens here
    except IntegrityError:
        raise ValueError(...)

This doesn't work. Django detects that an error occurred inside an atomic block, marks the transaction as broken, and raises TransactionManagementError on the next query. You can catch the IntegrityError, but you can't use the database connection afterward.

The fix is to wrap only the insert in a nested atomic block — a savepoint:

with transaction.atomic():                    # outer transaction
    if Membership.objects.filter(...).exists():
        raise ValueError(...)

    try:
        with transaction.atomic():            # ← savepoint
            membership = Membership.objects.create(...)
    except IntegrityError as exc:
        raise ValueError(...) from exc

    NotificationService.create(...)           # outer transaction still healthy
    return membership

The nested atomic() creates a SAVEPOINT in PostgreSQL. When the IntegrityError fires, only the savepoint rolls back. The outer transaction survives and remains usable.

I placed the savepoint only around the insert, not around the notification. Two reasons:

If the notification ever raised IntegrityError (a bug, not a race), converting it to "already a member" would be misleading.
The savepoint should be as small as possible — the tighter the scope, the more precise the semantics.

Step 6: The exception chaining detail

One subtle line matters more than it looks:

raise ValueError(...) from exc

That from exc preserves the exception chain. In production logs, the developer sees both:

ValueError: User user2 is already a member of workspace workspace-0
    ↑ caused by
IntegrityError: duplicate key value violates unique constraint "unique_membership"

The user gets a clean 400 Bad Request with a meaningful message. The developer gets a full stack trace explaining exactly what happened. Both win.

Step 7: Proving the fix at the API level

A service-level fix isn't enough. I also needed to prove that the HTTP contract held under concurrency. Two simultaneous POST requests to the members endpoint should produce exactly:

One 201 Created
One 400 Bad Request
Zero 500 Internal Server Error

The test:

@pytest.mark.django_db(transaction=True)
def test_concurrent_add_member_returns_201_and_400_not_500():
    # ... same threading setup ...

    def worker(user):
        try:
            client = APIClient()
            client.force_authenticate(user=user)
            barrier.wait()
            response = client.post(url, {'user': target.id})
            status_codes.append(response.status_code)
        finally:
            connection.close()

    # ... start and join threads ...

    assert set(status_codes) == {201, 400}, (
        f"Expected {{201, 400}}, got {status_codes}"
    )

Note the set() comparison. During development, I initially wrote:

assert sorted(status_codes) == [400, 201]

And got this beautifully confusing error:

AssertionError: Expected [201, 400], got [201, 400]

sorted() sorts ascending, so sorted([201, 400]) is [201, 400], not [400, 201]. Order-independent assertions need set, not sorted. Small mistake, big lesson: in concurrency tests, never assume order.

The result

Before the fix:

service test: ❌ Expected ValueError, got IntegrityError
API test:     ❌ Expected [201, 400], got [201, 500]

After the fix:

service test: ✅ exactly one ValueError, no IntegrityError
API test:     ✅ exactly {201, 400}, never 500
full suite:   ✅ all green

The full architecture came out cleaner too:

DB Layer      → unique constraint: data integrity protected
Service Layer → IntegrityError → ValueError: domain semantics enforced
API Layer     → ValueError → 400: HTTP contract preserved

No layer is overstepping its role. The view doesn't need to know about database constraints. The service doesn't need to know about HTTP status codes. Each layer converts errors into the language of the layer above it.

Section 3: Five Lessons I Took Away

Debugging a race condition in a single service method taught me more about backend architecture than any framework tutorial ever could. Here are the five lessons that stuck.

1. If your code uses check-then-create, you have a race condition

Every single time.

if not exists():
    create()

This pattern is everywhere in real codebases — and it's always wrong under concurrency. The window between check and act is small, but it's real, and under load it will be hit.

The fix isn't a smarter check. The fix is either a database constraint, a lock, or a caught exception. But it's never "just add another check."

2. The database constraint is not the bug — the error handling is

I initially thought the database had let me down because it threw an IntegrityError under load. It hadn't. The database was doing its job perfectly — protecting data integrity under concurrent access.

The bug was in my service layer: I hadn't accounted for the fact that the constraint could fire. The database is a safeguard, not a substitute for correct error handling.

Once I framed it that way, the fix became obvious: convert the database's error into the language of the domain.

3. Savepoints are not optional — they're the mechanism

When I first tried to catch IntegrityError inside a transaction, Django raised TransactionManagementError. I didn't understand why until I read the docs carefully.

The rule: once a transaction is broken, it's broken. You can't "undo" the break. But you can isolate the broken operation inside a savepoint so that the outer transaction never sees the damage.

This is what nested transaction.atomic() does. It's not a syntax trick — it's the way Django exposes PostgreSQL's savepoint semantics. Any error recovery inside a transaction requires it.

4. The right fix has zero cost in the normal path

Of the three solutions I considered, select_for_update was the most obviously safe. Lock the workspace, serialize the requests, done.

But it would serialize every add_member call, even the ones that never raced. In the common case — one user adding one member, no concurrency — I'd be paying for a lock I didn't need.

The exception-conversion approach has zero overhead in the normal path. Membership.objects.create() runs, succeeds, and no exception handler executes. Only in the rare race does the code take the except branch.

The best fix is often the one that does nothing in the common case.

5. Concurrency tests are the ones you'll never see fail — until production does

Every test in this project passed before I wrote the concurrency tests. Every single one. Unit tests, integration tests, API tests — green across the board.

They were green because they were testing the code the way developers write it: one call, one result. The race condition only exists when two calls happen at the same time.

If I hadn't written a test with threading.Barrier and transaction=True, this bug would have shipped. And it would have been invisible for months. And then one day, in production, with real users on real networks hitting real servers, some poor engineer would have seen a spike in 500s and had no idea where to start.

If a bug can only exist under concurrency, only a concurrency test can find it.

Final Thought

The pattern that caused this bug — if not exists(): create() — is the first thing most developers reach for. It's intuitive. It reads like English. It passes code review because it looks correct.

But "looks correct" and "is correct under load" are different things. The gap between them is where production bugs live.

What changed my approach wasn't learning a new library or memorizing a design pattern. It was accepting that any code touching shared state can be raced — and being willing to write the tests that prove it can't.

The fix itself was four lines. The savepoint around one .create(). The conversion from IntegrityError to ValueError. The preservation of the exception chain.

But those four lines are the difference between a 400 Bad Request and a 500 Internal Server Error. Between a system that degrades gracefully under load and one that collapses.

The next time you write if not exists(), pause. Ask yourself what happens if two users hit that line at the same time. If the answer is "I don't know" — that's the test to write.

Not every race condition has a race at its heart. But every one has a lesson.

About the author:

🔗 GitHub: https://github.com/majidkhazaei
🔗 LinkedIn: https://www.linkedin.com/in/majid-khazaei-dev

My Journey Contributing to Django REST Framework

Majid Khazaei — Sun, 13 Sep 2026 12:27:16 +0000

Section 1: The Bug That Sat Untouched for Over a Year

In September 2026, I merged my first Pull Request into Django REST Framework — one of the most widely used Python libraries in the world.

But the story didn't start with me. It started with a bug that was reported in May 2025 and sat untouched for over a year.

The bug was subtle but serious: DRF's serializer validation was rejecting perfectly valid data when using Django's UniqueConstraint with conditions.

Here's what that means in practice. Imagine you're building an API for a race tracking system. You want to enforce a simple rule:

"Only one race with a given name can have a position ≤ 1."

So you write this constraint:

UniqueConstraint(
    fields=['race_name'],
    condition=Q(position__lte=1),
    name='unique_top_race_name'
)

The database handles this correctly. It allows:

✅ Marathon, position=1
✅ Marathon, position=2
✅ Marathon, position=3

But DRF's serializer? It would incorrectly reject the third entry with a "unique set" error — even though the database would happily accept it.

The user experience was broken. Developers were forced to bypass the serializer and insert data directly into the database, which is exactly the kind of thing DRF exists to prevent.

The worst part? The issue was marked as "confusing" by one of the maintainers themselves. It involved complex interactions between Q objects, referenced_base_fields, nulls_distinct, and two competing validator classes.

Nobody wanted to touch it.

That's exactly why I did.

Section 2: The Journey — Reviving an Abandoned PR, Surviving Three Merge Conflicts, and Facing Copilot

Once I decided to tackle this bug, I discovered that someone had already started working on it — a developer named nefrob had opened a Pull Request months earlier, but it had stalled.

The PR had:

❌ Merge conflicts with the main branch
❌ Missing helper functions it depended on
❌ Unresolved reviewer feedback
❌ No activity for weeks

Most people would have walked away. Instead, I decided to revive it.

What I actually did

1. Rebased and resolved the initial conflicts.
I pulled the abandoned branch, resolved the merge conflicts, and added a missing helper function (get_referenced_base_fields_from_q) that the original author had referenced but never committed. Without it, the whole PR wouldn't even import.

2. Faced three rounds of new merge conflicts.
Every time a maintainer merged something new into main, my branch would break again. I resolved conflicts three separate times — each one requiring me to carefully combine my logic with changes from other contributors who were working on the same file.

3. Fixed four bugs found by GitHub Copilot.
Copilot reviewed my PR and found issues I had missed:

Empty constraint.fields — my code was creating validators with no fields, silently breaking validation.
Lost custom error messages — when multiple constraints shared the same fields, only the last one's message survived.
Condition fields not triggering revalidation — updates that only changed the condition field were silently accepted, even when they violated the database constraint.
A nulls_distinct edge case — partial updates were incorrectly skipping validation.

Each bug required careful investigation. Each one needed a test to prove the fix.

4. Got reviewed by a contributor who'd worked on the same code.
A contributor named MehrazRumman — who had recently merged his own PR touching the same file — reviewed my work in detail. He found two more issues:

A dead-code helper that could be removed entirely (since DRF only supports Django 5.2+, which already provides Q.referenced_base_fields).
A performance regression where partial updates triggered three unnecessary database queries instead of zero.

I applied both fixes. That meant deleting 20 lines of code I'd originally added — and that was the right call.

5. Passed the final review and got merged.
After 17 commits, 26 comments, and more than a month of back-and-forth, the PR was approved and merged by a DRF maintainer.

The result

The final change:

✅ Fixes incorrect validation for conditional UniqueConstraints
✅ Preserves custom error messages and error codes
✅ Correctly rechecks uniqueness when condition fields change
✅ Handles nulls_distinct edge cases
✅ Passes all 83 validator tests
✅ Merged into Django REST Framework

A bug that had been open for over a year — and that one maintainer openly called "confusing" — was finally closed.

Section 3: Five Lessons I Took Away (And Why They Matter Beyond Open Source)

Merging a PR into Django REST Framework taught me more than any tutorial could. Here are the five lessons that stuck with me — and that apply far beyond open source.

1. Reviving abandoned work is more valuable than starting from scratch

The original PR had been sitting untouched for months. Instead of writing my own solution from zero, I picked up where someone else left off — resolved the conflicts, filled in the gaps, and carried it across the finish line.

The lesson: In any team, the unfinished work of others is often the highest-leverage place to contribute. Don't ignore the graveyard of "almost done" projects.

2. Automated tools find what humans miss — but they don't replace judgment

GitHub Copilot found four bugs in my code that I had completely overlooked. Each one was subtle, each one was real, and each one would have caused problems in production.

But Copilot also made suggestions I chose not to follow — and I had to justify why. Automation is a force multiplier, not a decision-maker.

The lesson: Use AI tools aggressively to review your work, but always own the final call.

3. The best code is often less code

A reviewer pointed out that one of my helper functions was dead code — a compatibility shim for Django versions the project no longer supported. I deleted 20 lines I'd been proud of writing.

That deletion was the single best thing I did in the entire PR.

The lesson: Code you don't write is code you don't have to maintain, test, or debug. Simplicity is a feature.

4. Merge conflicts are a sign of a healthy project — not a broken one

I resolved conflicts three separate times during this PR. Every time, it meant other contributors were actively improving the same code I was touching.

A project with zero merge conflicts is usually a project with zero activity.

The lesson: Friction from collaboration is not a bug. It's the cost of working on something that matters.

5. Patience is a technical skill

From my first comment to the final merge, this took over a month. There were days of waiting for reviewers, weeks of silence from maintainers, and moments when I wondered if it was worth continuing.

It was. The maintainers are volunteers. The reviewers have day jobs. And the bug wasn't urgent — it had waited a year already. It could wait one more week.

The lesson: In open source — and in any long-running project — patience isn't passive. It's an active skill you have to practice.

Final thought

I didn't contribute to Django REST Framework because I'm an expert. I did it because I was willing to:

Read the issue carefully
Pick up someone else's unfinished work
Accept feedback without taking it personally
Delete my own code when it wasn't needed
Wait when waiting was the right move

A year-old bug that one maintainer called "confusing" is now closed. And a small piece of my work is running in thousands of production APIs around the world.

If you've been waiting for the "right moment" to contribute to open source — this is it.

Pick an issue. Start small. Be patient. Ship it.

About the author:

Majid Khazaei is a software engineer and open-source contributor.
He recently contributed to Django REST Framework, fixing a validation bug
that had been open for over a year (PR #10021).

🔗 GitHub: https://github.com/majidkhazaei
🔗 LinkedIn: https://www.linkedin.com/in/majid-khazaei-dev

DEV Community: Majid Khazaei

The Second Race Condition: When Updating a Record Is Just as Dangerous as Creating One

Section 1: The Bug That Didn't Announce Itself

Section 2: The Contracts That Came Before the Tests

Contract 1: Same-Role Concurrent Change

Contract 2: Different-Role Concurrent Change

Contract 3: Role Change + Remove

Section 3: The First RED — A Duplicate Notification

Section 4: The Fix — One Line

Section 5: The Second Bug — A Silent No-Op

Section 6: The Third Test — A Test Almost Broke

Section 7: One More Consideration — Deadlock Potential

Section 8: Five Lessons From the Second Bug

1. check-then-act isn't the only race-prone pattern

2. Silent no-ops are more dangerous than loud failures

3. In concurrency tests, choose roles that make the test order-independent

4. Lock only what you need — and always in the same order

5. A consistent pattern is worth more than a clever fix

Section 9: The Results

Final Thought

The Concurrency Bug That Only Appears Under Load: A Django Race Condition Story

Section 1: The Bug That Never Shows Up in Development

Section 2: The Journey — From a Green Test to a Hidden 500

Step 1: Writing the test that would expose everything

Step 2: When green isn't good enough

Step 3: Understanding the actual race

Step 4: Choosing between three fixes

Step 5: The nested atomic — and why it matters

Step 6: The exception chaining detail

Step 7: Proving the fix at the API level

The result

Section 3: Five Lessons I Took Away

1. If your code uses check-then-create, you have a race condition

2. The database constraint is not the bug — the error handling is

3. Savepoints are not optional — they're the mechanism

4. The right fix has zero cost in the normal path

5. Concurrency tests are the ones you'll never see fail — until production does

Final Thought

My Journey Contributing to Django REST Framework

Section 1: The Bug That Sat Untouched for Over a Year

Section 2: The Journey — Reviving an Abandoned PR, Surviving Three Merge Conflicts, and Facing Copilot

What I actually did

The result

Section 3: Five Lessons I Took Away (And Why They Matter Beyond Open Source)

1. Reviving abandoned work is more valuable than starting from scratch

2. Automated tools find what humans miss — but they don't replace judgment

3. The best code is often less code

4. Merge conflicts are a sign of a healthy project — not a broken one

5. Patience is a technical skill

Final thought

About the author:

1. `check-then-act` isn't the only race-prone pattern