Connecting signal handlers in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a signal handler is connected incorrectly?

Consider this Django signal connection code:

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=MyModel)
def my_handler(sender, instance, **kwargs):
    print('Saved:', instance)

What will happen if you forget to import MyModel correctly and connect the signal?

A The signal handler will be called for all models, ignoring the sender filter.

B Django will raise an ImportError at runtime when connecting the signal.

C The signal handler will be called twice for each save event.

D The signal handler will never be called because the sender is not recognized.

💡 Hint

Think about how the sender argument filters which model triggers the signal.

If the sender is not the correct model class, the signal handler won't be triggered for saves of that model. The handler is connected but never called because the sender filter doesn't match.

📝 Syntax

intermediate

Which option correctly connects a signal handler using the connect method?

You want to connect a function my_handler to Django's post_delete signal for MyModel. Which code snippet is correct?

A post_delete.connect(my_handler, sender=MyModel)

B post_delete.connect(sender=MyModel, my_handler)

C post_delete.connect(my_handler)

D post_delete.connect(my_handler, MyModel)

💡 Hint

Remember the order of arguments for the connect method.

The connect method takes the receiver function as the first argument and the sender as a keyword argument. Option A follows this pattern correctly.

❓ state_output

advanced

What is printed when a signal handler modifies instance data before saving?

Given this code:

from django.db.models.signals import pre_save
from django.dispatch import receiver

@receiver(pre_save, sender=MyModel)
def modify_name(sender, instance, **kwargs):
    instance.name = instance.name.upper()

obj = MyModel(name='hello')
obj.save()
print(obj.name)

What will be printed?

A hello

B HELLO

C None

D An error is raised

💡 Hint

The pre_save signal runs before the model instance is saved.

The pre_save signal handler changes the instance's name to uppercase before saving. The saved instance and the variable obj reflect this change, so printing obj.name outputs 'HELLO'.

🔧 Debug

advanced

Why does this signal handler run multiple times unexpectedly?

This code connects a signal handler inside a Django view function:

def my_view(request):
    from django.db.models.signals import post_save

    def handler(sender, instance, **kwargs):
        print('Saved:', instance)

    post_save.connect(handler, sender=MyModel)
    # ... rest of view code ...
    return HttpResponse('Done')

Why might the handler print multiple times on multiple requests?

A Because the signal connection happens on every request, adding duplicate handlers.

B Because post_save signals are only sent once per model class.

C Because the handler function is defined inside the view, it is not recognized.

D Because Django caches signal handlers and reuses them.

💡 Hint

Think about where the connect call is placed and how often the view runs.

Connecting a signal handler inside a view means it runs every time the view is called, adding a new handler each time. This causes multiple prints for one save event.

🧠 Conceptual

expert

What is the effect of using dispatch_uid when connecting signal handlers?

In Django signals, what does providing a unique dispatch_uid argument to connect do?

A Filters signals to only those with matching dispatch_uid.

B Changes the order in which signal handlers are called.

C Prevents the same signal handler from being connected multiple times.

D Makes the signal handler run asynchronously.

💡 Hint

Think about how Django avoids duplicate signal connections.

The dispatch_uid argument uniquely identifies a signal handler connection. If a handler with the same dispatch_uid is connected again, Django ignores it, preventing duplicates.

Practice

1. What is the main purpose of connecting signal handlers in Django?

easy

A. To style HTML templates dynamically

B. To manually call functions from views

C. To create new database tables

D. To automatically run code when certain model events happen

Solution

1. Step 1: Understand signal handlers

   Signal handlers let Django apps respond automatically to events like saving or deleting a model.

2. Step 2: Identify the purpose

   Connecting signal handlers means running code automatically when these events happen, without manual calls.

3. Final Answer:

   To automatically run code when certain model events happen -> Option D

4. Quick Check:

   Signal handlers = automatic event response [OK]

Hint: Signals run code automatically on model events [OK]

Common Mistakes:

• Thinking signals create database tables
• Confusing signals with manual function calls
• Assuming signals style templates

2. Which of the following is the correct way to connect a signal handler using the decorator in Django?

easy

A. @receiver(post_save, sender=MyModel)
def my_handler(sender, instance, **kwargs): pass

B. @signal(post_save, sender=MyModel)
def my_handler(sender, instance): pass

C. @connect(post_save, sender=MyModel)
def my_handler(instance): pass

D. @listen(post_save, sender=MyModel)
def my_handler(sender): pass

Solution

1. Step 1: Recall the correct decorator

   Django uses @receiver to connect signal handlers, not @signal, @connect, or @listen.

2. Step 2: Check function parameters

   The handler must accept sender, instance, and optionally **kwargs. @receiver(post_save, sender=MyModel) def my_handler(sender, instance, **kwargs): pass matches this.

3. Final Answer:

   @receiver(post_save, sender=MyModel) def my_handler(sender, instance, **kwargs): pass -> Option A

4. Quick Check:

   Use @receiver with correct params [OK]

Hint: Use @receiver decorator with sender and signal [OK]

Common Mistakes:

• Using wrong decorator names
• Missing sender argument
• Incorrect handler parameters

3. Given this code snippet, what will be printed when a new Book instance is created?

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=Book)
def announce_book(sender, instance, created, **kwargs):
    if created:
        print(f"New book added: {instance.title}")

book = Book.objects.create(title='Django Basics')

medium

A. New book added:

B. New book added: Django Basics

C. No output

D. Error: missing argument

Solution

1. Step 1: Understand the signal and handler

   The post_save signal triggers after saving a model. The handler checks if created is True, meaning a new record.

2. Step 2: Analyze the code execution

   Creating a new Book instance sets created=True, so the print statement runs with the title.

3. Final Answer:

   New book added: Django Basics -> Option B

4. Quick Check:

   post_save with created=True prints title [OK]

Hint: Check 'created' flag to print on new records only [OK]

Common Mistakes:

• Ignoring the 'created' flag
• Assuming no output on create
• Confusing signal arguments

4. Identify the error in this signal handler connection code:

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save)
def handler(sender, instance, **kwargs):
    print('Saved!')

medium

A. Missing sender argument in @receiver decorator

B. Handler function missing 'created' parameter

C. post_save signal is not imported correctly

D. Handler function should not have **kwargs

Solution

1. Step 1: Check the @receiver decorator usage

   The @receiver decorator requires the signal and optionally the sender. Omitting sender means the handler listens to all senders, which is allowed but often unintended.

2. Step 2: Identify the likely error

   Since the question asks for an error, the missing sender argument is the problem if the handler is meant for a specific model.

3. Final Answer:

   Missing sender argument in @receiver decorator -> Option A

4. Quick Check:

   Specify sender to target model signals [OK]

Hint: Always specify sender to avoid catching all signals [OK]

Common Mistakes:

• Not specifying sender when needed
• Assuming 'created' param is always required
• Misunderstanding **kwargs usage

5. You want to run a function only when a new UserProfile is created, not when updated. Which is the best way to connect the signal handler?

hard

A. Use @receiver(post_save) without sender and ignore created flag

B. Use @receiver(pre_save, sender=UserProfile) and always run the function

C. Use @receiver(post_save, sender=UserProfile) and check if created is True inside the handler

D. Use @receiver(post_delete, sender=UserProfile) to detect creation

Solution

1. Step 1: Identify the correct signal for creation

   post_save runs after saving, and the created flag tells if it's a new record.

2. Step 2: Choose the best method

   Using @receiver(post_save, sender=UserProfile) and checking created inside the handler ensures the function runs only on creation.

3. Final Answer:

   Use @receiver(post_save, sender=UserProfile) and check if created is True inside the handler -> Option C

4. Quick Check:

   post_save + created=True = run on new only [OK]

Hint: Check 'created' flag in post_save for new records only [OK]

Common Mistakes:

• Using pre_save which runs before saving
• Using post_delete which runs on deletion
• Ignoring the created flag and running always