DEV Community: Django Mastery

Your Celery task will run twice. Here's how to make that safe

Django Mastery — Fri, 02 Oct 2026 19:58:01 +0000

Celery can't promise a task runs exactly once. It can run twice, and one day it will. If that task sends an email or charges a card, your user gets two.

The fix isn't to stop duplicates. It's to make the second run do nothing.

How a task ends up running twice

With acks_late=True, the message stays unacknowledged while the task runs. Now picture this:

A worker runs send_order_confirmation. The email goes out.
The worker is killed (out of memory, a pod eviction) before it acks.
The broker redelivers: RabbitMQ when the connection drops, Redis after the visibility timeout.
Another worker runs the task again. Second email.

And it's not only crashes:

an autoretry after a timeout where the other side actually succeeded,
a user double-clicking a button,
a scheduled task overlapping its previous run,
a task that runs longer than the visibility timeout.

Pick your failure mode

Setting	Crash during the task	Guarantee
Default (early ack)	The task is lost	At-most-once
`acks_late=True`	The task runs again	At-least-once

For anything important, pick acks_late plus idempotency.

One catch: with task_reject_on_worker_lost, a task that always runs out of memory gets redelivered forever. Cap it with a delivery counter or time limits.

So exactly-once execution isn't available. Aim for an exactly-once effect instead.

The strongest guard: a unique constraint

class EmailLog(models.Model):
    kind = models.CharField(max_length=50)
    object_id = models.BigIntegerField()
    sent_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["kind", "object_id"],
                name="uniq_email_per_object",
            ),
        ]


@shared_task
def send_order_confirmation(order_id: int) -> None:
    try:
        with transaction.atomic():
            EmailLog.objects.create(kind="order_confirmation", object_id=order_id)
            send_confirmation_email(order_id)
    except IntegrityError:
        return

How it works:

Claim the work first by inserting the log row. A duplicate run raises IntegrityError right there, so it exits quietly.
If sending fails, the exception rolls back the log row too, so a retry can still run.
The database enforces it, even when two workers hit the same order at the same moment.

Use this for anything that should happen once per object: emails, notifications, certificates, payouts.

Bonus: task states and their gotchas

State	Meaning	Gotcha
`PENDING`	Waiting, or unknown id	A typo'd id is PENDING forever
`STARTED`	A worker began	Only with `task_track_started = True`
`RETRY`	Failed, retry scheduled	A new message, same task id
`SUCCESS`	Returned normally	Needs a result backend to be visible
`FAILURE`	Raised, no retries left	Traceback stored if enabled
`REVOKED`	Cancelled with `revoke()`	A running task goes on unless `terminate=True`

Quick check

acks_late=True is on. A worker sends an email, then is killed before acking. What happens?

It runs again and sends a second email, unless the task is idempotent. Celery has no idea the email already went out.

Remember

Exactly-once execution doesn't exist; aim for an exactly-once effect.
acks_late plus idempotency for important work.
A unique constraint is the strongest duplicate guard.

This article and the video are a free sample from Django Mastery, a video course with 306 short animated lessons that takes you from your first model to production deployment (Django 6.1 and 5.2 LTS), including a full level on Celery and background jobs.

👉 Full course: https://djangomastery.gumroad.com/l/django-mastery
📺 More free lessons: https://www.youtube.com/@Django-Mastery

The course and this article were produced with AI assistance, and the video uses AI narration.

The N+1 query problem in Django: how 3 lines send 101 queries

Django Mastery — Fri, 02 Oct 2026 14:41:17 +0000

Here's a loop that looks completely harmless:

orders = Order.objects.all()
for order in orders:
    print(order.customer.name)

Three lines. Show each order with its customer's name. With 100 orders, this sends 101 queries to your database.

What actually happens

Order.objects.all() builds a query but sends nothing yet. QuerySets are lazy.
The loop starts, so Django fetches the orders. That's 1 query.
order.customer is a foreign key that isn't loaded yet. Every time the loop touches it, Django asks the database again. That's 1 query per order.

100 orders = 1 + 100 = 101 queries. That's the N+1 problem: one query for the list, plus one for every row.

At around 2 ms per query, that's 200 ms added to a single page, and it grows with your data. It looks fine on your laptop with 5 rows and melts in production.

The fix is one method call

orders = Order.objects.select_related("customer")
for order in orders:
    print(order.customer.name)

select_related joins the customer into the same query. The loop then reads it from memory. Same loop, same output: 101 queries become 1.

select_related or prefetch_related?

The relation you follow	Use	Queries
One object: ForeignKey, OneToOne (`order.customer`)	`select_related()`	1 (JOIN)
Many objects: reverse FK, ManyToMany (`order.items.all()`)	`prefetch_related()`	2 (second query with `IN`)

Catch it before production

django-debug-toolbar shows how many queries each page ran.
assertNumQueries in a test fails the day someone reintroduces the loop:

def test_order_list_queries(self):
    with self.assertNumQueries(2):
        self.client.get("/orders/")

Django 6.1: fetch_mode(models.FETCH_RAISE) turns a hidden lazy query into an error, which is great in tests.

Quick check

A view loops over 50 blog posts and prints post.author.name. How many queries without any fix?

51. One for the posts, plus one per post for its author. select_related("author") brings it down to 1.

Remember

Looping over rows and touching a related field? Check the query count.
select_related for one related object, prefetch_related for many.
Measure with the debug toolbar; lock it in with assertNumQueries.

👉 Full course: https://djangomastery.gumroad.com/l/django-mastery
📺 More free lessons: https://www.youtube.com/@Django-Mastery

The course and this article were produced with AI assistance, and the video uses AI narration.