dj-signals

Enqueue Django signal receiver tasks inside the same database transaction with Celery.

109|6|Updated Apr 4, 2026
One-click install
npx skills add https://github.com/dvf/opinionated-django --skill dj-signals
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dj-signals
Source: https://github.com/dvf/opinionated-django/tree/main/skills/dj-signals
Command: npx skills add https://github.com/dvf/opinionated-django --skill dj-signals

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Standard Django signals are synchronous and unreliable: receiver failures propagate errors to the sender, there is no delivery guarantee if the process crashes after a database commit, and there is no built-in retry mechanism for failed side-effect tasks like notifications or cache invalidation.

Core Features & Use Cases

  • Implements the reliable signals pattern using Celery to enqueue receiver tasks inside the same database transaction as the business operation, so tasks roll back automatically if the transaction fails and are guaranteed to be queued on successful commit.
  • Enforces idempotent receiver design to safely handle at-least-once delivery from Celery, preventing duplicate side-effects from repeated task execution.
  • Use cases include triggering post-commit work such as user notifications, cache invalidation, analytics logging, or cross-service coordination tied to Django business operations.

Quick Start

Use the dj-signals skill to add a reliable async signal for new user registration emails in your Django project, ensuring the email task is only queued after the user account is successfully saved to the database.

Frequently Asked Questions about dj-signals

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I ensure Django signals run only after a database transaction is successfully committed?

To ensure Django signals run post-commit, you can use the reliable signals pattern with Celery to enqueue receiver tasks inside the same database transaction. This guarantees tasks are queued only on successful commit and roll back if the transaction fails.

Why do standard Django signals fail to execute side-effect tasks like notifications reliably?

Standard Django signals fail because they are synchronous, causing receiver failures to propagate errors to the sender. They lack delivery guarantees if the process crashes after a database commit and have no built-in retry mechanism for failed side-effect tasks.

How do I prevent duplicate side-effects when Celery retries a failed Django signal receiver task?

To prevent duplicate side-effects from Celery retries, you must design idempotent receivers that safely handle at-least-once delivery. This ensures repeated task execution does not trigger duplicate notifications or other side-effect operations.

What is the best way to pass data to async Django signal receivers without direct ORM imports?

The best way to pass data to async Django signal receivers is using JSON-serializable identifiers passed via repositories. This restricts receiver data access to serialized IDs instead of direct ORM imports, ensuring safe async execution.

What are the limitations of using synchronous Django signals for post-commit work?

Synchronous Django signals limit post-commit work by lacking delivery guarantees upon process crashes and having no retry mechanism. Receiver failures also propagate errors directly to the sender, disrupting the core business operation.