django-ox 0.1.0__tar.gz

django_ox-0.1.0/.gitignore

@@ -0,0 +1,12 @@
+__pycache__/
+*.py[cod]
+*.egg-info/
+dist/
+.venv/
+*.sqlite3
+.pytest_cache/
+.coverage*
+.mypy_cache/
+.ruff_cache/
+site/
+benchmarks/logs/

django_ox-0.1.0/CHANGELOG.md

@@ -0,0 +1,85 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [0.1.0] - 2026-08-13
+
+Initial release.
+
+### Added
+
+- `OxBackend`, a database-backed backend for Django's Tasks framework
+  (`django.tasks`, Django 6.0+). Tasks are stored in the application database;
+  no broker required.
+- Transactional enqueue: `enqueue()` is a single INSERT on the caller's
+  connection, so a task enqueued inside `transaction.atomic()` commits or
+  rolls back with the business data.
+- `ox_worker` management command: claims tasks with
+  `SELECT ... FOR UPDATE SKIP LOCKED` where supported (PostgreSQL, MySQL 8+)
+  and an atomic compare-and-set UPDATE elsewhere (including SQLite).
+  Configurable via `--backend`, `--queues`, `--concurrency` (thread pool),
+  `--interval`, and `--lock-timeout`.
+- Retries with exponential backoff (`MAX_ATTEMPTS`, `BACKOFF_INITIAL`,
+  `BACKOFF_MAX`), keeping the full traceback of every attempt.
+- Reaper: tasks whose worker died are returned to the queue after
+  `LOCK_TIMEOUT` and count as a failed attempt.
+- Graceful drain: on SIGTERM/SIGINT the worker stops claiming, finishes
+  in-flight tasks, then exits; a second signal forces an immediate exit.
+- Priorities (-100 to 100, higher first) and deferred tasks (`run_after`),
+  with the corresponding `supports_*` flags declared on the backend.
+- Result store: `get_result()`, `refresh()`, and the async variants, with
+  status, return value, and per-attempt errors readable from the database.
+- `ox_prune` management command: batched deletion of finished task rows
+  (`--older-than`, `--include-failed`, `--batch-size`, `--dry-run`).
+- `django_ox.stats`: read-only queue metrics as plain ORM queries, on
+  both supported databases: per-queue status counts, backlog depth and
+  age, throughput and failure rate over a trailing window, and time
+  since the last task claim.
+- `ox_health` management command: exits non-zero with a one-line reason
+  when the database is unreachable or a `--max-backlog`, `--max-age` or
+  `--worker-timeout` threshold is breached; built for cron alerting and
+  container probes.
+- Structured logging: worker lifecycle events (claim, start, success,
+  retry, failure, reclaim, dispatch, shutdown) log to the `django_ox`
+  logger with stable extra keys (`event`, `task_id`, `queue`, `attempt`,
+  `duration_ms`, ...) for JSON log handlers.
+- Recurring tasks: cron schedules declared in the `TASKS` setting
+  (`SCHEDULES` option), dispatched by the workers themselves; a unique
+  constraint on (schedule, tick) makes each tick fire exactly once across
+  any number of workers. Five-field cron syntax plus `@hourly`-style
+  shortcuts; misconfigured schedules fail at startup and in
+  `manage.py check`. On recovery after downtime, only the latest missed
+  tick fires.
+- System check `django_ox.E003`: a schedule name defined on more than
+  one backend is rejected, at worker startup and in `manage.py check`,
+  because the tick log is keyed by schedule name alone and shared names
+  would let the backends suppress each other's ticks.
+
+### Fixed
+
+Findings from a pre-release adversarial review:
+
+- A tick row dated in the future (for example written by a worker with a
+  fast clock) no longer suppresses schedule dispatch fleet-wide; ticks
+  that are due now fire regardless, and the unique constraint still
+  protects the future instant itself.
+- Cron step values larger than the field's range (such as `*/61` in the
+  minute field, which silently collapsed to minute 0) are rejected at
+  parse time.
+
+### Security
+
+- A stored `task_path` is now required to resolve to a `django.tasks` Task
+  (a function registered with `@task`). A row naming any other importable
+  callable is rejected as an un-runnable task instead of being executed, so
+  the worker never invokes an arbitrary dotted path pulled from the table.
+  `SECURITY.md` documents the full trust model, the JSON-only
+  serialization, and the guidance to keep secrets out of task arguments.
+- Added an API stability and deprecation policy (`docs/stability.md`):
+  the public API surface, the pre-1.0 SemVer rule, the deprecation window,
+  and the supported Python and Django matrix.
+
+[0.1.0]: https://github.com/oxpull/django-ox/releases/tag/v0.1.0

django_ox-0.1.0/LICENSE

@@ -0,0 +1,29 @@
+BSD 3-Clause License
+
+Copyright (c) 2026, [COMPANY]
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

django_ox-0.1.0/PKG-INFO

@@ -0,0 +1,253 @@
+Metadata-Version: 2.5
+Name: django-ox
+Version: 0.1.0
+Summary: Database-backed worker backend for Django's Tasks framework.
+Project-URL: Homepage, https://github.com/oxpull/django-ox
+Project-URL: Repository, https://github.com/oxpull/django-ox
+Project-URL: Changelog, https://github.com/oxpull/django-ox/blob/main/CHANGELOG.md
+Project-URL: Issues, https://github.com/oxpull/django-ox/issues
+Author: Oxpull
+License-Expression: BSD-3-Clause
+License-File: LICENSE
+Keywords: background-tasks,database,django,queue,task-queue,tasks,worker
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Web Environment
+Classifier: Framework :: Django
+Classifier: Framework :: Django :: 6.0
+Classifier: Framework :: Django :: 6.1
+Classifier: Intended Audience :: Developers
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Software Development :: Libraries :: Python Modules
+Requires-Python: >=3.12
+Requires-Dist: django>=6.0
+Description-Content-Type: text/markdown
+
+# django-ox
+
+A database-backed worker backend for Django's Tasks framework (`django.tasks`, Django 6.0+).
+
+Django 6.0 ships the Tasks API but no production backend: the built-in
+`ImmediateBackend` and `DummyBackend` are for development and testing only.
+django-ox stores tasks in your existing database and runs them with a
+separate worker process, so you get a durable queue without adding a broker.
+
+## Durability model
+
+`enqueue()` is a single INSERT on your default database connection, so it
+participates in the caller's open transaction. A task enqueued inside
+`transaction.atomic()` becomes visible to workers only when the transaction
+commits, and disappears on rollback. There is no window where business data
+exists without its task, or a task without its data, and no
+`transaction.on_commit()` boilerplate. Execution is at-least-once: workers
+claim tasks with `SELECT ... FOR UPDATE SKIP LOCKED` on databases that support
+it (PostgreSQL, MySQL 8+) and an atomic compare-and-set UPDATE elsewhere
+(including SQLite), and a reaper returns tasks whose worker died to the queue.
+Failed tasks retry with exponential backoff up to a configurable attempt
+limit, keeping the full traceback of every attempt.
+
+## Install
+
+Requires Python 3.12+ and Django 6.0+.
+
+```
+pip install django-ox
+```
+
+```python
+INSTALLED_APPS = [
+    # ...
+    "django_ox",
+]
+
+TASKS = {
+    "default": {
+        "BACKEND": "django_ox.backend.OxBackend",
+        "QUEUES": ["default", "emails"],  # [] allows any queue name
+        "OPTIONS": {
+            "MAX_ATTEMPTS": 3,  # executions per task before FAILED
+            "LOCK_TIMEOUT": 300,  # seconds before a dead worker's task is reclaimed
+            "BACKOFF_INITIAL": 5,  # first retry delay, seconds; doubles per attempt
+            "BACKOFF_MAX": 600,  # retry delay ceiling, seconds
+        },
+    }
+}
+```
+
+Then run migrations:
+
+```
+python manage.py migrate django_ox
+```
+
+## Quickstart
+
+Tasks are plain `django.tasks` tasks; django-ox adds nothing to learn on the
+producer side.
+
+```python
+from django.tasks import task
+
+
+@task
+def send_welcome_email(user_id): ...
+
+
+result = send_welcome_email.enqueue(user_id=42)
+result.refresh()  # later: status, return_value, errors
+```
+
+Run a worker:
+
+```
+python manage.py ox_worker
+```
+
+## Worker CLI
+
+| Flag | Default | Meaning |
+| --- | --- | --- |
+| `--backend` | `default` | Backend alias from the `TASKS` setting. |
+| `--queues` | all configured queues | Comma-separated queue names to process. |
+| `--concurrency` | `1` | Tasks executed concurrently (thread pool). |
+| `--interval` | `1.0` | Polling interval in seconds when idle. |
+| `--lock-timeout` | backend `LOCK_TIMEOUT` | Seconds before a stuck task is reclaimed. |
+
+On SIGTERM or SIGINT the worker stops claiming, finishes in-flight tasks, then
+exits. A second signal forces an immediate exit.
+
+## Pruning
+
+Finished task rows stay in the table until pruned. Run `ox_prune` on your
+own schedule (cron, systemd timer):
+
+```
+python manage.py ox_prune --older-than 7d
+```
+
+| Flag | Default | Meaning |
+| --- | --- | --- |
+| `--older-than` | `7d` | Minimum time since the task finished. Accepts `7d`, `24h`, `90m`, `45s`, or a plain number of seconds. |
+| `--include-failed` | off | Also delete FAILED rows. By default they are kept: they hold the per-attempt tracebacks. |
+| `--batch-size` | `1000` | Rows per DELETE statement, so pruning a large table never takes a long lock or builds a giant IN clause. |
+| `--dry-run` | off | Report how many rows would be deleted without deleting any. |
+
+Only SUCCESSFUL rows (and, with `--include-failed`, FAILED rows) past the
+cutoff are deleted. READY and RUNNING rows are never touched, whatever their
+age. Old rows from the recurring-schedule tick log are cleared with the same
+cutoff, always keeping each schedule's most recent tick.
+
+## Health and monitoring
+
+`django_ox.stats` exposes queue metrics as plain functions, each a single
+ORM query: per-queue status counts, backlog depth and age, throughput,
+and failure rate. The `ox_health` command turns thresholds on those
+numbers into an exit code for cron alerting and container probes:
+
+```
+python manage.py ox_health --max-backlog 1000 --max-age 600
+```
+
+| Flag | Default | Meaning |
+| --- | --- | --- |
+| `--queue` | all queues | Restrict the checks to one queue. |
+| `--max-backlog` | off | Fail when more than this many READY tasks are eligible to run. |
+| `--max-age` | off | Fail when the oldest waiting task has waited longer than this many seconds. |
+| `--worker-timeout` | off | Fail when no worker has claimed a task within this many seconds. |
+
+Worker lifecycle events (claim, start, success, retry, failure, reclaim,
+shutdown) log to the `django_ox` logger with stable extra keys (task id,
+queue, attempt, duration), ready for JSON log handlers.
+
+## Recurring tasks
+
+Schedules are declared in settings, next to the backend they enqueue
+through, and deploy with your code. There are no rows to edit by hand and
+no separate scheduler process to keep alive:
+
+```python
+TASKS = {
+    "default": {
+        "BACKEND": "django_ox.backend.OxBackend",
+        "QUEUES": ["default", "emails"],
+        "OPTIONS": {
+            "SCHEDULES": {
+                "nightly-report": {
+                    "task": "reports.tasks.build_report",
+                    "cron": "0 3 * * *",
+                    "kwargs": {"full": True},
+                },
+                "warm-cache": {
+                    "task": "core.tasks.warm_cache",
+                    "cron": "*/15 * * * *",
+                },
+            },
+        },
+    }
+}
+```
+
+Each tick enqueues a normal task instance, which workers claim and execute
+through the ordinary queue: retries, backoff, priorities and the result
+store all apply unchanged. Every running worker doubles as the scheduler,
+and a unique constraint on (schedule name, tick time) makes each tick fire
+exactly once however many workers are polling.
+
+| Key | Required | Meaning |
+| --- | --- | --- |
+| `task` | yes | Dotted path to a `@task` callable, e.g. `"reports.tasks.build_report"`. |
+| `cron` | yes | Five-field cron expression. |
+| `args`, `kwargs` | no | JSON-serializable arguments passed to each enqueue. |
+| `queue_name` | no | Queue override; defaults to the task's own queue. |
+| `priority` | no | Priority override (-100 to 100). |
+
+Cron expressions use the classic five-field syntax: `*`, lists (`1,15`),
+ranges (`mon-fri`), steps (`*/15`), month and weekday names, 0 or 7 for
+Sunday, and the `@hourly`, `@daily`, `@weekly`, `@monthly` and `@yearly`
+shortcuts. When both day-of-month and day-of-week are restricted, a day
+matches if either field does, as in vixie cron. Times are wall-clock in
+your `TIME_ZONE`.
+
+Misconfigured schedules (a task path that does not import, an expression
+that can never fire) fail at worker startup and in `manage.py check`, not
+silently at dispatch time.
+
+Missed ticks: if every worker was down when a tick passed, the latest
+missed tick fires once on recovery and older ones are skipped, so a
+nightly job still runs after an unlucky deploy window but a backlog never
+stampedes. A newly deployed schedule waits for its next tick rather than
+firing for a time before it existed.
+
+## Behavior details
+
+- `run_after` (deferred tasks), `priority` (-100 to 100, higher runs first),
+  `get_result()` and the async variants are all supported; the backend
+  declares `supports_defer`, `supports_priority`, `supports_get_result` and
+  `supports_async_task` accordingly.
+- Retry state is visible in the database: attempts, per-attempt tracebacks,
+  and the next scheduled run (`run_after`).
+- Because execution is at-least-once, tasks should be idempotent. A task is
+  retried both when it raises and when its worker dies mid-run.
+- Concurrency uses a thread pool. That fits I/O-bound tasks (email, HTTP,
+  ORM); for CPU-bound work, run multiple worker processes with
+  `--concurrency=1` instead.
+
+## Not yet supported
+
+- Task revocation or cancellation after enqueue.
+- Multi-database routing (tasks are stored on the default database for the
+  model).
+- Rate limiting, batching, and a dashboard.
+
+## Stability
+
+What counts as public API, the pre-1.0 versioning and deprecation policy,
+and the supported Python and Django versions are documented in
+[docs/stability.md](docs/stability.md).
+
+## License
+
+BSD 3-Clause.

django_ox-0.1.0/README.md

@@ -0,0 +1,225 @@
+# django-ox
+
+A database-backed worker backend for Django's Tasks framework (`django.tasks`, Django 6.0+).
+
+Django 6.0 ships the Tasks API but no production backend: the built-in
+`ImmediateBackend` and `DummyBackend` are for development and testing only.
+django-ox stores tasks in your existing database and runs them with a
+separate worker process, so you get a durable queue without adding a broker.
+
+## Durability model
+
+`enqueue()` is a single INSERT on your default database connection, so it
+participates in the caller's open transaction. A task enqueued inside
+`transaction.atomic()` becomes visible to workers only when the transaction
+commits, and disappears on rollback. There is no window where business data
+exists without its task, or a task without its data, and no
+`transaction.on_commit()` boilerplate. Execution is at-least-once: workers
+claim tasks with `SELECT ... FOR UPDATE SKIP LOCKED` on databases that support
+it (PostgreSQL, MySQL 8+) and an atomic compare-and-set UPDATE elsewhere
+(including SQLite), and a reaper returns tasks whose worker died to the queue.
+Failed tasks retry with exponential backoff up to a configurable attempt
+limit, keeping the full traceback of every attempt.
+
+## Install
+
+Requires Python 3.12+ and Django 6.0+.
+
+```
+pip install django-ox
+```
+
+```python
+INSTALLED_APPS = [
+    # ...
+    "django_ox",
+]
+
+TASKS = {
+    "default": {
+        "BACKEND": "django_ox.backend.OxBackend",
+        "QUEUES": ["default", "emails"],  # [] allows any queue name
+        "OPTIONS": {
+            "MAX_ATTEMPTS": 3,  # executions per task before FAILED
+            "LOCK_TIMEOUT": 300,  # seconds before a dead worker's task is reclaimed
+            "BACKOFF_INITIAL": 5,  # first retry delay, seconds; doubles per attempt
+            "BACKOFF_MAX": 600,  # retry delay ceiling, seconds
+        },
+    }
+}
+```
+
+Then run migrations:
+
+```
+python manage.py migrate django_ox
+```
+
+## Quickstart
+
+Tasks are plain `django.tasks` tasks; django-ox adds nothing to learn on the
+producer side.
+
+```python
+from django.tasks import task
+
+
+@task
+def send_welcome_email(user_id): ...
+
+
+result = send_welcome_email.enqueue(user_id=42)
+result.refresh()  # later: status, return_value, errors
+```
+
+Run a worker:
+
+```
+python manage.py ox_worker
+```
+
+## Worker CLI
+
+| Flag | Default | Meaning |
+| --- | --- | --- |
+| `--backend` | `default` | Backend alias from the `TASKS` setting. |
+| `--queues` | all configured queues | Comma-separated queue names to process. |
+| `--concurrency` | `1` | Tasks executed concurrently (thread pool). |
+| `--interval` | `1.0` | Polling interval in seconds when idle. |
+| `--lock-timeout` | backend `LOCK_TIMEOUT` | Seconds before a stuck task is reclaimed. |
+
+On SIGTERM or SIGINT the worker stops claiming, finishes in-flight tasks, then
+exits. A second signal forces an immediate exit.
+
+## Pruning
+
+Finished task rows stay in the table until pruned. Run `ox_prune` on your
+own schedule (cron, systemd timer):
+
+```
+python manage.py ox_prune --older-than 7d
+```
+
+| Flag | Default | Meaning |
+| --- | --- | --- |
+| `--older-than` | `7d` | Minimum time since the task finished. Accepts `7d`, `24h`, `90m`, `45s`, or a plain number of seconds. |
+| `--include-failed` | off | Also delete FAILED rows. By default they are kept: they hold the per-attempt tracebacks. |
+| `--batch-size` | `1000` | Rows per DELETE statement, so pruning a large table never takes a long lock or builds a giant IN clause. |
+| `--dry-run` | off | Report how many rows would be deleted without deleting any. |
+
+Only SUCCESSFUL rows (and, with `--include-failed`, FAILED rows) past the
+cutoff are deleted. READY and RUNNING rows are never touched, whatever their
+age. Old rows from the recurring-schedule tick log are cleared with the same
+cutoff, always keeping each schedule's most recent tick.
+
+## Health and monitoring
+
+`django_ox.stats` exposes queue metrics as plain functions, each a single
+ORM query: per-queue status counts, backlog depth and age, throughput,
+and failure rate. The `ox_health` command turns thresholds on those
+numbers into an exit code for cron alerting and container probes:
+
+```
+python manage.py ox_health --max-backlog 1000 --max-age 600
+```
+
+| Flag | Default | Meaning |
+| --- | --- | --- |
+| `--queue` | all queues | Restrict the checks to one queue. |
+| `--max-backlog` | off | Fail when more than this many READY tasks are eligible to run. |
+| `--max-age` | off | Fail when the oldest waiting task has waited longer than this many seconds. |
+| `--worker-timeout` | off | Fail when no worker has claimed a task within this many seconds. |
+
+Worker lifecycle events (claim, start, success, retry, failure, reclaim,
+shutdown) log to the `django_ox` logger with stable extra keys (task id,
+queue, attempt, duration), ready for JSON log handlers.
+
+## Recurring tasks
+
+Schedules are declared in settings, next to the backend they enqueue
+through, and deploy with your code. There are no rows to edit by hand and
+no separate scheduler process to keep alive:
+
+```python
+TASKS = {
+    "default": {
+        "BACKEND": "django_ox.backend.OxBackend",
+        "QUEUES": ["default", "emails"],
+        "OPTIONS": {
+            "SCHEDULES": {
+                "nightly-report": {
+                    "task": "reports.tasks.build_report",
+                    "cron": "0 3 * * *",
+                    "kwargs": {"full": True},
+                },
+                "warm-cache": {
+                    "task": "core.tasks.warm_cache",
+                    "cron": "*/15 * * * *",
+                },
+            },
+        },
+    }
+}
+```
+
+Each tick enqueues a normal task instance, which workers claim and execute
+through the ordinary queue: retries, backoff, priorities and the result
+store all apply unchanged. Every running worker doubles as the scheduler,
+and a unique constraint on (schedule name, tick time) makes each tick fire
+exactly once however many workers are polling.
+
+| Key | Required | Meaning |
+| --- | --- | --- |
+| `task` | yes | Dotted path to a `@task` callable, e.g. `"reports.tasks.build_report"`. |
+| `cron` | yes | Five-field cron expression. |
+| `args`, `kwargs` | no | JSON-serializable arguments passed to each enqueue. |
+| `queue_name` | no | Queue override; defaults to the task's own queue. |
+| `priority` | no | Priority override (-100 to 100). |
+
+Cron expressions use the classic five-field syntax: `*`, lists (`1,15`),
+ranges (`mon-fri`), steps (`*/15`), month and weekday names, 0 or 7 for
+Sunday, and the `@hourly`, `@daily`, `@weekly`, `@monthly` and `@yearly`
+shortcuts. When both day-of-month and day-of-week are restricted, a day
+matches if either field does, as in vixie cron. Times are wall-clock in
+your `TIME_ZONE`.
+
+Misconfigured schedules (a task path that does not import, an expression
+that can never fire) fail at worker startup and in `manage.py check`, not
+silently at dispatch time.
+
+Missed ticks: if every worker was down when a tick passed, the latest
+missed tick fires once on recovery and older ones are skipped, so a
+nightly job still runs after an unlucky deploy window but a backlog never
+stampedes. A newly deployed schedule waits for its next tick rather than
+firing for a time before it existed.
+
+## Behavior details
+
+- `run_after` (deferred tasks), `priority` (-100 to 100, higher runs first),
+  `get_result()` and the async variants are all supported; the backend
+  declares `supports_defer`, `supports_priority`, `supports_get_result` and
+  `supports_async_task` accordingly.
+- Retry state is visible in the database: attempts, per-attempt tracebacks,
+  and the next scheduled run (`run_after`).
+- Because execution is at-least-once, tasks should be idempotent. A task is
+  retried both when it raises and when its worker dies mid-run.
+- Concurrency uses a thread pool. That fits I/O-bound tasks (email, HTTP,
+  ORM); for CPU-bound work, run multiple worker processes with
+  `--concurrency=1` instead.
+
+## Not yet supported
+
+- Task revocation or cancellation after enqueue.
+- Multi-database routing (tasks are stored on the default database for the
+  model).
+- Rate limiting, batching, and a dashboard.
+
+## Stability
+
+What counts as public API, the pre-1.0 versioning and deprecation policy,
+and the supported Python and Django versions are documented in
+[docs/stability.md](docs/stability.md).
+
+## License
+
+BSD 3-Clause.