Calling tasks asynchronously in Django - Step-by-Step Execution

Concept Flow - Calling tasks asynchronously

Define task function

↓

Trigger async call

↓

Task queued in broker

↓

Worker picks task

↓

Task runs in background

↓

Result stored or ignored

↓

Main app continues immediately

This flow shows how a task is defined, called asynchronously, queued, executed by a worker, and how the main app continues without waiting.

Execution Sample

Django

from celery import shared_task

@shared_task
def add(x, y):
    return x + y

add.delay(4, 6)

Defines a task to add two numbers and calls it asynchronously using delay().

Execution Table

Step	Action	Evaluation	Result
1	Define task function 'add'	Function 'add' ready for async	Task registered with Celery
2	Call add.delay(4, 6)	Creates async task message	Task message sent to broker queue
3	Worker receives task	Worker picks 'add' task with args (4,6)	Task starts running in background
4	Task executes add(4,6)	Calculates 4 + 6	Returns 10
5	Result stored or ignored	Result saved if backend configured	Main app not blocked, continues immediately

💡 Task completes asynchronously; main app never waits for result.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
x	undefined	4	4	4
y	undefined	6	6	6
result	undefined	undefined	10	10

Key Moments - 3 Insights

Why doesn't the main app wait for the task result after calling add.delay(4, 6)?

Because add.delay() sends the task to a queue and returns immediately without blocking, as shown in execution_table step 2 and 5.

How does the worker know when to run the task?

The worker listens to the broker queue and picks tasks as they arrive, shown in execution_table step 3.

What happens if the result backend is not configured?

The task runs and completes, but the result is not stored or retrievable, so the main app cannot get the output.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of add(4, 6) at step 4?

A Undefined

B 4

C 10

D 6

💡 Hint

Check the 'Result' column at step 4 in the execution_table.

At which step does the main app continue without waiting?

A Step 1

B Step 5

C Step 2

D Step 4

💡 Hint

Look at the 'Action' and 'Result' columns describing main app behavior.

If we call add(4, 6) directly instead of add.delay(4, 6), what changes in the execution?

A Main app waits for the result before continuing

B Task runs asynchronously as before

C Task is queued but not executed

D Worker ignores the task

💡 Hint

Compare the difference between synchronous call and delay() in the concept_flow.

Concept Snapshot

Define a task with @shared_task decorator.
Call task asynchronously with task.delay(args).
Task is queued and run by worker in background.
Main app continues immediately without waiting.
Result stored only if backend configured.
Use for long or slow operations to avoid blocking.

Full Transcript

In Django with Celery, you define a task function using @shared_task. When you call this task with .delay(), it sends a message to a broker queue and returns immediately. A worker process listens to this queue and runs the task in the background. The main application does not wait for the task to finish and continues its work. The task result can be stored if a result backend is set up, but the main app does not block waiting for it. This allows long-running tasks to run asynchronously without slowing down the user experience.

Practice

1. What is the main purpose of calling tasks asynchronously in a Django app using Celery?

easy

A. To avoid using any external libraries

B. To make the app run slower by adding extra steps

C. To run time-consuming tasks in the background without blocking the main app

D. To run tasks only when the server restarts

Solution

1. Step 1: Understand asynchronous task calling

   Calling tasks asynchronously means running them in the background so the main app can continue working without waiting.

2. Step 2: Identify the benefit in Django apps

   This helps keep the app fast and responsive by not blocking user requests with long tasks.

3. Final Answer:

   To run time-consuming tasks in the background without blocking the main app -> Option C

4. Quick Check:

   Async tasks = background work = To run time-consuming tasks in the background without blocking the main app [OK]

Hint: Async tasks run in background, keeping app responsive [OK]

Common Mistakes:

• Thinking async tasks slow down the app
• Believing async tasks run only on server restart
• Confusing async with avoiding external libraries

2. Which of the following is the correct way to call a Celery task named send_email asynchronously?

easy

A. send_email.delay()

B. send_email()

C. send_email.async()

D. send_email.run()

Solution

1. Step 1: Recall Celery task calling syntax

   Celery tasks are called asynchronously using the .delay() method.

2. Step 2: Match the correct method to the task name

   Calling send_email.delay() queues the task to run in the background.

3. Final Answer:

   send_email.delay() -> Option A

4. Quick Check:

   Use .delay() to call async tasks [OK]

Hint: Use .delay() to call Celery tasks asynchronously [OK]

Common Mistakes:

• Calling the task like a normal function without .delay()
• Using .async() which is not a Celery method
• Using .run() which executes task synchronously

3. Given the following Celery task and call:

@shared_task
def add(x, y):
    return x + y

result = add.delay(4, 5)

What will result.get() return after the task completes?

medium

A. 9

B. None

C. An error because .get() is not valid

D. A task ID string

Solution

1. Step 1: Understand what add.delay(4, 5) does

   This queues the add task with arguments 4 and 5 to run asynchronously.

2. Step 2: Understand result.get() usage

   Calling result.get() waits for the task to finish and returns the result, which is 4 + 5 = 9.

3. Final Answer:

   9 -> Option A

4. Quick Check:

   Task result = 4 + 5 = 9 [OK]

Hint: Use .get() to fetch async task result after completion [OK]

Common Mistakes:

• Thinking .get() returns task ID instead of result
• Believing .get() is invalid for Celery AsyncResult
• Expecting None because task runs asynchronously

4. What is wrong with this Celery task call?

@shared_task
def multiply(x, y):
    return x * y

result = multiply(3, 7)

medium

A. The arguments 3 and 7 are invalid types

B. The task is missing the @app.task decorator

C. The function multiply should not return a value

D. The task is called synchronously, not asynchronously

Solution

1. Step 1: Check how the task is called

   The task is called directly as multiply(3, 7), which runs it immediately and blocks.

2. Step 2: Identify correct async call method

   To call asynchronously, it should be multiply.delay(3, 7).

3. Final Answer:

   The task is called synchronously, not asynchronously -> Option D

4. Quick Check:

   Direct call runs sync, use .delay() for async [OK]

Hint: Use .delay() to call tasks async, not direct function call [OK]

Common Mistakes:

• Calling task function directly instead of using .delay()
• Confusing @shared_task with @app.task (both valid but different)
• Thinking return values are disallowed in tasks

5. You want to send a welcome email asynchronously after a user registers. Which approach correctly combines Django signals and Celery tasks to achieve this?

hard

A. Call send_welcome_email(user.id) directly inside the signal handler

B. Connect a signal handler that calls send_welcome_email.delay(user.id) after user creation

C. Use a signal to call send_welcome_email.run(user.id) synchronously

D. Call send_welcome_email.delay() before the user is saved

Solution

1. Step 1: Understand the goal

   We want to send the email asynchronously after the user is created to avoid slowing registration.

2. Step 2: Use Django signals with Celery correctly

   Connect a signal (like post_save) to call send_welcome_email.delay(user.id) after user creation, queuing the task.

3. Final Answer:

   Connect a signal handler that calls send_welcome_email.delay(user.id) after user creation -> Option B

4. Quick Check:

   Signal + .delay() after save = async email send [OK]

Hint: Use signals to trigger .delay() after user save [OK]

Common Mistakes:

• Calling task directly inside signal, blocking request
• Calling .run() which is synchronous
• Calling .delay() before user exists in DB