Signals, Tasks & Email

send_mail() sends one message, optionally with an html_message alternative, to a recipient list that all appear in To. For CC, BCC, Reply-To, custom headers or attachments, build an EmailMessage, or an EmailMultiAlternatives to add body versions.

Connect a receiver to post_save with sender=settings.AUTH_USER_MODEL and create the Profile only when the created argument is True, so later saves of the same user do not insert a second profile.

QuerySet.update(), bulk_create() and bulk_update() write SQL directly and send no pre_save or post_save; raw SQL sends nothing; DB_CASCADE deletes (Django 6.1) send no delete signals. QuerySet.delete() still sends pre_delete and post_delete per object.

The task is queued before the transaction commits, so the worker's separate connection may not see the order yet. Queue it with transaction.on_commit(), or Celery's delay_on_commit() on Django projects, so the message is sent only after commit.

Decorate a module-level function with @task from django.tasks, then call make_thumbnail.enqueue(photo.pk) in the view; enqueue() hands the call to the configured TASKS backend and returns a TaskResult instead of running the function in the view.

With namespace='CELERY', Celery reads each option as an uppercase CELERY_-prefixed Django setting: broker_url becomes CELERY_BROKER_URL. A plain BROKER_URL or a lowercase broker_url in settings.py is never read, so the default broker is used.

@shared_task creates a task without importing a concrete Celery app, so a Django app never imports the project's celery module; autodiscover_tasks() then imports each installed app's tasks.py so the task is registered with the project's app.

Django ships smtp, console, filebased, locmem and dummy backends. Use console or filebased in development, let the test runner swap in locmem for tests, and use SMTP or a provider's backend in production. Only SMTP is meant for production.

mail_admins() emails the addresses in ADMINS, from SERVER_EMAIL (default 'root@localhost'), with EMAIL_SUBJECT_PREFIX ('[Django] ') prepended to the subject. It returns without sending if ADMINS is empty. mail_managers() does the same for MANAGERS.

ModelForm.save() saves the instance, firing post_save, and only then writes the many-to-many rows, so the receiver sees the old relations. m2m_changed fires on add, remove, clear and set, with the through model as sender.

Define receivers in a signals submodule and import it from AppConfig.ready(), so they connect once after the app registry is loaded; pass dispatch_uid when the same receiver could be connected twice under different identities.

Django ships no worker. The default ImmediateBackend runs each task synchronously inside enqueue(); DummyBackend stores results and never runs them. Both are for development and tests; production needs a third-party backend with a durable queue and worker process.

Store TaskResult.id, then call task.get_result(id) or the backend's get_result(id) and read status: READY, RUNNING, FAILED or SUCCESSFUL. return_value works only after success; errors holds failures. Built-in backends cannot fetch results across processes.

Celery serialises task arguments, JSON by default, and a Django model instance is not JSON-serialisable. Even with pickle, an instance is a stale snapshot; passing order.pk lets the task load current data and handle a deleted row.

Django's email backends are synchronous, so send_mail() holds the request while it connects and talks SMTP, and the SMTP backend has no timeout unless you set one. Set the mailer's timeout, then move sending off the request into a task run by a real worker.

The exception propagates out of save() into the view. Inside an atomic block the row is rolled back; in autocommit the row is already written. send() lets errors escape; send_robust() catches and returns them, but only for signals you send yourself.

Task arguments and return values go through a JSON round-trip so another process can run the task, so a model instance or datetime raises TypeError. Pass the primary key and re-fetch the row inside the task, handling a deleted or uncommitted row.

Use signals when you cannot edit the sender, such as a third-party app or contrib model, or when one app must react to another without importing it. Inside your own code, prefer explicit service calls: visible, testable, and not bypassed by bulk writes.

Define both aliases in the MAILERS setting, each with a BACKEND and OPTIONS. Pass using='marketing' to send_mail(), EmailMessage.send() or mail_admins(), or take a backend from django.core.mail.mailers['marketing']. Without using=, the 'default' alias sends.

priority, queue_name and takes_context are set in @task; run_after only through Task.using(), which returns a modified copy. The backend validates each: unsupported deferral or priority, unknown queues or a bad context signature raise InvalidTask.