--- id: wiki-2026-0508-django-signals title: Django Signals category: 10_Wiki/Topics status: verified canonical_id: self aliases: [Django Signal Framework, dispatch signals] duplicate_of: none source_trust_level: A confidence_score: 0.9 verification_status: applied tags: [django, python, observer-pattern, backend, decoupling] raw_sources: [] last_reinforced: 2026-05-10 github_commit: pending tech_stack: language: python framework: django-5 --- # Django Signals ## 매 한 줄 > **"매 in-process pub/sub for Django — observer pattern over the ORM lifecycle"**. Django signals 는 sender/receiver 의 decouple 하는 dispatch 메커니즘 — 2005 Django core 에 도입, 2026 현재 Django 5.1 LTS 까지 안정. 매 ORM hook (post_save, pre_delete) + custom signal 의 emit 의 standard way. ## 매 핵심 ### 매 작동 원리 - **django.dispatch.Signal**: receiver list 의 weakref 보관 — 매 GC safe. - **send() vs send_robust()**: send 의 raise on receiver error, send_robust 의 collect exceptions in result list — 매 production 의 send_robust 권장. - **Synchronous**: 매 in-process, in-thread — 매 transaction.on_commit() 통해 post-commit 의 schedule. - **Async receivers (5.0+)**: 매 async def receiver 의 native support. ### 매 built-in signals - **Model**: pre_save, post_save, pre_delete, post_delete, m2m_changed, pre_init, post_init. - **Request**: request_started, request_finished, got_request_exception. - **Auth**: user_logged_in, user_logged_out, user_login_failed. - **Migration**: pre_migrate, post_migrate. ### 매 응용 1. Audit log — 매 model save 의 log 기록. 2. Cache invalidation — 매 ORM update 시 cache key purge. 3. Side-effect dispatch — 매 user signup → email send. ## 💻 패턴 ### Receiver registration with @receiver ```python # myapp/signals.py from django.db.models.signals import post_save from django.dispatch import receiver from django.conf import settings from .models import Profile @receiver(post_save, sender=settings.AUTH_USER_MODEL) def create_user_profile(sender, instance, created, **kwargs): if created: Profile.objects.create(user=instance) ``` ### AppConfig.ready() 의 signal import ```python # myapp/apps.py from django.apps import AppConfig class MyAppConfig(AppConfig): name = "myapp" def ready(self): from . import signals # noqa: F401 — register receivers ``` ### Custom signal ```python # myapp/signals.py from django.dispatch import Signal order_paid = Signal() # providing_args deprecated in 4.0+ # In a view/service after payment order_paid.send(sender=Order, order=order, amount=order.total) # Receiver @receiver(order_paid) def send_receipt(sender, order, amount, **kwargs): EmailService.send_receipt(order, amount) ``` ### Transaction-safe side effects ```python from django.db import transaction from django.db.models.signals import post_save @receiver(post_save, sender=Order) def enqueue_fulfillment(sender, instance, created, **kwargs): if not created: return transaction.on_commit( lambda: fulfillment_queue.enqueue(instance.pk) ) ``` ### Async receiver (Django 5.0+) ```python from asgiref.sync import sync_to_async @receiver(post_save, sender=Comment) async def notify_subscribers(sender, instance, **kwargs): await broadcast_to_channel(f"post-{instance.post_id}", { "event": "new_comment", "id": instance.pk, }) ``` ### Robust dispatch with error collection ```python results = order_paid.send_robust(sender=Order, order=order) for receiver_fn, response in results: if isinstance(response, Exception): logger.exception("receiver %s failed", receiver_fn, exc_info=response) ``` ### Cache invalidation ```python from django.core.cache import cache from django.db.models.signals import post_save, post_delete @receiver([post_save, post_delete], sender=Article) def purge_article_cache(sender, instance, **kwargs): cache.delete(f"article:{instance.pk}") cache.delete_pattern("articles:list:*") # if django-redis ``` ### Disconnect for testing ```python import pytest from django.db.models.signals import post_save from myapp.signals import create_user_profile @pytest.fixture(autouse=True) def _silence_profile_signal(): post_save.disconnect(create_user_profile, sender=User) yield post_save.connect(create_user_profile, sender=User) ``` ## 매 결정 기준 | 상황 | Approach | |---|---| | Cross-app decouple side-effect | Signal ✅ | | Same-app, deterministic flow | Direct method call (signal 불필요) | | Heavy work (email, ML inference) | Signal → enqueue Celery/RQ task | | Cross-process / cross-service | Kafka/RabbitMQ — 매 signal 은 in-process 만 | | Need ordering / replay | Outbox pattern + message broker | **기본값**: signal 은 light decouple 만, heavy work 는 즉시 task queue 의 enqueue. ## 🔗 Graph - 부모: [[Observer-Pattern]] - 변형: [[Django Signals]] · (blinker) ## 🤖 LLM 활용 **언제**: in-process decoupling 이 필요할 때, ORM lifecycle hook (post_save 등) 이 자연스러울 때, 매 third-party app 의 own model 의 alter 못할 때. **언제 X**: cross-service eventing — 매 Kafka/Outbox 의 use; complex workflow orchestration — 매 Celery chain / Temporal 의 use; testability 가 critical 한 critical path — 매 explicit service call 의 prefer. ## ❌ 안티패턴 - **Heavy work in receiver**: 매 sync send 면 request latency 의 block — Celery enqueue. - **Signals for in-app flow**: 매 traceability 의 lose — 매 explicit method call 의 use. - **No transaction.on_commit**: post_save 시점 의 transaction 미commit — race condition 발생. - **Forgetting weak=False**: lambda receiver 가 GC 의 collected — 매 module-level def 또는 weak=False. - **Test pollution**: signal 의 test 사이 의 leak — fixture 의 disconnect. ## 🧪 검증 / 중복 - Verified (docs.djangoproject.com/en/5.1/topics/signals/, Django source dispatch/dispatcher.py). - 신뢰도 A. ## 🕓 Changelog | 날짜 | 변경 | |---|---| | 2026-05-08 | Phase 1 | | 2026-05-10 | Manual cleanup — Django 5.1 signal patterns + async receiver + transaction.on_commit |