In Django, when exactly does a transaction.on_commit() callback registered inside a nested atomic block run, and when is it dropped?

## Terms first - An **atomic block** is `transaction.atomic()`; only the **outermost** one opens and commits the transaction. - A **nested** block creates a **savepoint** — a marker the transaction can roll back to — and on normal exit merely releases it. - `transaction.on_commit(func)` registers `func` to run after the transaction commits. ## How Django tracks callbacks When you register a callback inside a transaction, the connection stores it together with the **set of savepoint IDs active at that moment**. Two events act on that list: 1. **Rolling back to a savepoint** removes every callback whose recorded set contains that savepoint — the ones registered inside the failed block, including deeper nested blocks. 2. **Committing the outermost block** runs the remaining callbacks, in registration order, once autocommit is back on; a **full rollback** clears the list. Releasing a savepoint (a nested block exiting normally) runs nothing. ## Walking through the receipt flow ```python with transaction.atomic(): # transaction order = Order.objects.create(...) transaction.on_commit(partial(send_receipt, order.pk)) # A try: with transaction.atomic(): # savepoint apply_voucher(order) transaction.on_commit(partial(notify_voucher, order.pk)) # B raise VoucherExpired() except VoucherExpired: pass transaction.on_commit(partial(update_stats, order.pk)) # C # after commit: A, then C run; B was dropped with its savepoint ``` | Callback | Registered in | Fate | |---|---|---| | A | outer block | runs after commit | | B | inner block that rolled back | removed at savepoint rollback | | C | outer block, after the recovery | runs after commit, after A | Had the inner block succeeded, B would also run — after the outer commit, between A and C, not at the inner block's exit. ## Timing relative to the rest of the request - **Explicit block**: callbacks run inside the `with` statement's exit, before the next line of your function. - **`ATOMIC_REQUESTS`**: the view is wrapped in the outermost block, so callbacks run as the view returns — before middleware sees the response and before a `TemplateResponse` is rendered. A slow callback delays the response. - **No block, autocommit**: the callable runs immediately inside `on_commit()`. ## Edge cases worth naming - **Callbacks registered by callbacks**: by the time a callback runs, the transaction is over and the connection is back in autocommit, so an `on_commit()` call made inside it runs its callable immediately. - **Other aliases**: a callback registered with `using="ledger"` waits for the `ledger` transaction, not for `default`. - **Swallowed errors**: if a database error is caught *inside* an atomic block rather than around it, that block still rolls back on exit and the callbacks registered inside it are discarded — the email silently never goes out. ## Why this design Callbacks follow the data: a callback describes a side effect of writes, so it lives or dies with the savepoint that holds those writes. That lets a service function register its own follow-ups without knowing whether a caller has wrapped it in a larger transaction. ## How interviewers probe it - They nest a block, raise inside it, catch outside, and ask which callbacks run — the answer turns on which savepoint was active at registration. - They ask whether the inner block's exit triggers anything — it does not. - They ask where the callback runs relative to the HTTP response under `ATOMIC_REQUESTS` — inside the handler, before middleware. Answering with the savepoint-set rule, rather than a memorised example, handles every variant they can construct.