dj-queue 0.13.0__tar.gz → 0.14.0__tar.gz

{dj_queue-0.13.0 → dj_queue-0.14.0}/PKG-INFO

@@ -1,19 +1,20 @@
 Metadata-Version: 2.4
 Name: dj-queue
-Version: 0.13.0
+Version: 0.14.0
 Summary: Database-backed task queue backend for Django’s Tasks framework.
 License-Expression: MIT
 License-File: LICENSE
 Classifier: Development Status :: 4 - Beta
 Classifier: Framework :: Django
 Classifier: Framework :: Django :: 6.0
+Classifier: Framework :: Django :: 6.1
 Classifier: Intended Audience :: Developers
 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-Dist: django>=6.0.0
+Requires-Dist: django>=6.0.0,<6.2
 Requires-Dist: psycopg>=3.3.3 ; extra == 'postgres'
 Requires-Dist: prometheus-client>=0.4.0 ; extra == 'prometheus'
 Requires-Python: >=3.12
@@ -39,7 +40,7 @@ It keeps the queue, live execution state, runtime metadata, and task results in
 
 - no Redis, RabbitMQ, or separate result store
 - PostgreSQL is the first-class production backend
-- MySQL 8+, MariaDB 10.6+, and SQLite are supported
+- MySQL, MariaDB, and SQLite are supported at Django's version floors
 - immediate, scheduled, recurring, and concurrency-limited work
 
 `dj_queue` is inspired by Rails' [Solid Queue](https://github.com/rails/solid_queue),
@@ -66,7 +67,7 @@ see [docs/benchmarks/](docs/benchmarks/) for the latest published reports.
 
 ## Installation
 
-`dj_queue` requires Python 3.12+ and Django 6.0+.
+`dj_queue` requires Python 3.12+ and supports Django 6.0 and 6.1.
 
 Install the package:
 
@@ -74,6 +75,9 @@ Install the package:
 pip install dj-queue
 ```
 
+The package includes inline public API annotations and a `py.typed` marker for
+PEP 561-compatible type checkers.
+
 Optional extras:
 
 ```bash
@@ -131,6 +135,7 @@ Define a task with Django's `@task` decorator:
 # myapp/tasks.py
 from django.tasks import task
 
+
 @task
 def add(a, b):
   return a + b
@@ -352,10 +357,21 @@ If you need to pass model instances, files, or custom objects, store them elsewh
 | Backend | Support level | Notes |
 |---|---|---|
 | PostgreSQL | first-class | polling, `SKIP LOCKED`, and optional `LISTEN/NOTIFY` |
-| MySQL 8+ | supported | polling plus `SKIP LOCKED` |
-| MariaDB 10.6+ | supported | polling plus `SKIP LOCKED` |
+| MySQL | supported | polling plus `SKIP LOCKED` |
+| MariaDB | supported | polling plus `SKIP LOCKED` |
 | SQLite | supported with limits | polling only, serialized writes, no `SKIP LOCKED`, no `LISTEN/NOTIFY`; practical for development, CI, and smaller deployments |
 
+The database floor follows the selected Django release:
+
+| Django | PostgreSQL | MySQL | MariaDB | SQLite |
+|---|---|---|---|---|
+| 6.0 | 14+ | 8.0.11+ | 10.6+ | 3.31+ |
+| 6.1 | 15+ | 8.4+ | 10.11+ | 3.37+ |
+
+CI keeps the floors on Django 6.0 and tests newer database lines through
+PostgreSQL 18, MySQL 9.7 and 26.7, and MariaDB 12.3. Django 6.1 only runs with
+database versions that it supports.
+
 For MySQL or MariaDB, install and configure a Django-compatible driver following Django's database docs.
 
 Other Django database vendors are rejected explicitly.
@@ -364,6 +380,70 @@ Polling is the portability path everywhere. Backend-specific features improve la
 
 For production PostgreSQL operational guidance, see [Postgres Queue Health](#postgres-queue-health).
 
+## Rolling Upgrades
+
+`dj_queue` supports live queue writes during a one-generation N/N−1 rolling
+upgrade. Schema changes use an expand, bridge, activate, and contract sequence:
+
+- release N adds nullable fields and writes both old and new representations
+- N and N−1 workers and producers can use the expanded schema together
+- release N+1 can activate the new representation after N−1 has left the fleet
+- a later release removes compatibility fields only after its oldest supported writer no longer needs them
+
+Each N release must name its minimum rollout-compatible N−1 patch. That patch
+must already retry transient database conflicts because release N cannot change
+the behavior of a process that is still running N−1.
+
+Use this deployment order:
+
+1. Upgrade all application and queue processes to the minimum compatible N−1 patch.
+2. Run `python manage.py dj_queue_health --deep` for queue processes and
+   invariants. Use your deployment platform to confirm that no older application
+   producer remains.
+3. Apply release N migrations once.
+4. Roll application producers and queue processes from N−1 to N.
+5. Run `python manage.py dj_queue_health --deep --require-version <N version>` for
+   queue processes. Use your deployment platform to confirm that no N−1
+   application producer remains.
+
+Each registered queue process stores its exact `dj_queue` version and rollout
+protocol generation. Deep health rejects a missing or incompatible protocol.
+`--require-version` also rejects a live queue process on another package
+version. Application producers do not register process rows, so check those in
+your deployment platform.
+
+A code rollback from N to N−1 keeps the expanded schema in place. Do not reverse
+the database migration during a live rollback. N−2 processes and skipped bridge
+releases are not supported.
+
+Expansion migrations keep one DDL operation per hot table migration so lock
+conflicts can retry safely. Constraints that a supported database cannot add
+online stay deferred until a later activation or contract release.
+
+This contract covers `dj_queue`'s schema and runtime. Jobs can outlive an
+application deployment, so keep your task import paths and accepted argument
+shapes compatible. Use a new task name when a payload change cannot be backward
+compatible.
+
+Maintainers can prove a candidate rollout against two immutable revisions:
+
+```bash
+bin/prerelease.py \
+  --from-ref <release-n-1-ref> \
+  --to-ref <release-n-ref> \
+  --backend postgres \
+  --django '>=6.0,<6.1'
+```
+
+The command calibrates release N−1, applies release N migrations under live
+writes, runs both versions together, drains with release N, and verifies queue
+state and side effects. It rejects revisions that do not publish one shared
+rollout protocol. It writes wheel hashes, one-second metrics, logs, and a result
+manifest under `benchmark-results/`. The **Pre-release migration load** workflow
+runs the database floor and current-version lanes. `--smoke` and custom workload
+profiles keep all validity and stability gates and record performance. Only the
+default ten-minute release profile enforces the X-to-Y performance ratios.
+
 ## Recurring Tasks
 
 `dj_queue` supports both static recurring tasks from settings and dynamic
@@ -445,27 +525,33 @@ Notes:
 
 Tasks can opt into database-backed concurrency limits.
 
-`django.tasks` has no standard way to pass backend-specific options through the
-`@task` decorator, so `dj_queue` reads them as attributes on the wrapped function:
+Use `dj_queue.api.concurrency` with Django's `@task` decorator:
 
 ```python
 from django.tasks import task
+from dj_queue.api import concurrency
+
 
 @task
+@concurrency(
+  key="account:{account_id}",
+  limit=1,
+  duration=60,
+  on_conflict="block",
+)
 def sync_account(account_id, action):
   return f"{account_id}:{action}"
-
-sync_account.func.concurrency_key = "account:{account_id}"
-sync_account.func.concurrency_limit = 1
-sync_account.func.concurrency_duration = 60
-sync_account.func.on_conflict = "block"
 ```
 
 With this configuration:
 
 - the first matching job can run immediately
 - later jobs for the same key can block until capacity is released
-- `on_conflict = "discard"` turns the same pattern into singleton-style work
+- `on_conflict="discard"` turns the same pattern into singleton-style work
+
+The concurrency key can be a format string or a callable. Both decorator orders
+are supported, but placing `@task` above `@concurrency` keeps backend-specific
+options next to the task function.
 
 Semaphore rows remain shared on the queue database. If you want per-backend
 isolation for a limit, express that in the `concurrency_key` itself rather than
@@ -511,10 +597,13 @@ Operational commands:
 
 ```bash
 python manage.py dj_queue_health
+python manage.py dj_queue_health --deep
 python manage.py dj_queue_health --max-age 120
+python manage.py dj_queue_health --deep --require-version 0.13.0
 python manage.py dj_queue_prune --older-than 86400
 python manage.py dj_queue_prune --failed-older-than 604800
 python manage.py dj_queue_prune --recurring-older-than 2592000
+python manage.py dj_queue_prune --batch-size 500
 python manage.py dj_queue_prune --task-path myapp.tasks.cleanup
 python manage.py dj_queue_prune --task-key nightly_cleanup
 python manage.py dj_queue_postgres_autovacuum
@@ -522,9 +611,16 @@ python manage.py dj_queue_postgres_autovacuum
 
 The health, prune, and PostgreSQL autovacuum commands accept `--backend` to target a non-default backend alias.
 
+`dj_queue_health` exits with status `1` and prints a reason when no process is
+live. Add `--deep` to check persisted queue invariants and live process rollout
+protocols. Add `--require-version` to require one exact package version across
+all live queue processes.
+
 For `dj_queue_prune`, `--task-path` filters finished and failed job cleanup by
 task import path, while `--task-key` filters recurring execution cleanup by
-recurring task key.
+recurring task key. One invocation deletes at most `--batch-size` rows from
+each retained row type. Run it again when it reports that the batch limit was
+reached.
 
 ## Failed Jobs
 
@@ -596,14 +692,17 @@ Each callback receives the live supervisor or runner instance.
 ```python
 from dj_queue.hooks import on_start, on_worker_start, register_hook
 
+
 @on_start
 def supervisor_started(process):
   print(process.name)
 
+
 @on_worker_start
 def worker_started(process):
   print(process.metadata)
 
+
 @register_hook("scheduler.exit")
 def scheduler_exited(process):
   print(process.name)
@@ -890,6 +989,10 @@ Configuration precedence is explicit:
 - TOML file pointed to by `DJ_QUEUE_CONFIG`
 - Django `TASKS` settings
 
+Unknown option names are rejected in Django settings and in the selected TOML
+overlay, including nested worker, dispatcher, scheduler, and recurring task
+options. The error identifies the exact configuration path and option name.
+
 ### TOML file config
 
 ```bash

{dj_queue-0.13.0 → dj_queue-0.14.0}/README.md

@@ -13,7 +13,7 @@ It keeps the queue, live execution state, runtime metadata, and task results in
 
 - no Redis, RabbitMQ, or separate result store
 - PostgreSQL is the first-class production backend
-- MySQL 8+, MariaDB 10.6+, and SQLite are supported
+- MySQL, MariaDB, and SQLite are supported at Django's version floors
 - immediate, scheduled, recurring, and concurrency-limited work
 
 `dj_queue` is inspired by Rails' [Solid Queue](https://github.com/rails/solid_queue),
@@ -40,7 +40,7 @@ see [docs/benchmarks/](docs/benchmarks/) for the latest published reports.
 
 ## Installation
 
-`dj_queue` requires Python 3.12+ and Django 6.0+.
+`dj_queue` requires Python 3.12+ and supports Django 6.0 and 6.1.
 
 Install the package:
 
@@ -48,6 +48,9 @@ Install the package:
 pip install dj-queue
 ```
 
+The package includes inline public API annotations and a `py.typed` marker for
+PEP 561-compatible type checkers.
+
 Optional extras:
 
 ```bash
@@ -105,6 +108,7 @@ Define a task with Django's `@task` decorator:
 # myapp/tasks.py
 from django.tasks import task
 
+
 @task
 def add(a, b):
   return a + b
@@ -326,10 +330,21 @@ If you need to pass model instances, files, or custom objects, store them elsewh
 | Backend | Support level | Notes |
 |---|---|---|
 | PostgreSQL | first-class | polling, `SKIP LOCKED`, and optional `LISTEN/NOTIFY` |
-| MySQL 8+ | supported | polling plus `SKIP LOCKED` |
-| MariaDB 10.6+ | supported | polling plus `SKIP LOCKED` |
+| MySQL | supported | polling plus `SKIP LOCKED` |
+| MariaDB | supported | polling plus `SKIP LOCKED` |
 | SQLite | supported with limits | polling only, serialized writes, no `SKIP LOCKED`, no `LISTEN/NOTIFY`; practical for development, CI, and smaller deployments |
 
+The database floor follows the selected Django release:
+
+| Django | PostgreSQL | MySQL | MariaDB | SQLite |
+|---|---|---|---|---|
+| 6.0 | 14+ | 8.0.11+ | 10.6+ | 3.31+ |
+| 6.1 | 15+ | 8.4+ | 10.11+ | 3.37+ |
+
+CI keeps the floors on Django 6.0 and tests newer database lines through
+PostgreSQL 18, MySQL 9.7 and 26.7, and MariaDB 12.3. Django 6.1 only runs with
+database versions that it supports.
+
 For MySQL or MariaDB, install and configure a Django-compatible driver following Django's database docs.
 
 Other Django database vendors are rejected explicitly.
@@ -338,6 +353,70 @@ Polling is the portability path everywhere. Backend-specific features improve la
 
 For production PostgreSQL operational guidance, see [Postgres Queue Health](#postgres-queue-health).
 
+## Rolling Upgrades
+
+`dj_queue` supports live queue writes during a one-generation N/N−1 rolling
+upgrade. Schema changes use an expand, bridge, activate, and contract sequence:
+
+- release N adds nullable fields and writes both old and new representations
+- N and N−1 workers and producers can use the expanded schema together
+- release N+1 can activate the new representation after N−1 has left the fleet
+- a later release removes compatibility fields only after its oldest supported writer no longer needs them
+
+Each N release must name its minimum rollout-compatible N−1 patch. That patch
+must already retry transient database conflicts because release N cannot change
+the behavior of a process that is still running N−1.
+
+Use this deployment order:
+
+1. Upgrade all application and queue processes to the minimum compatible N−1 patch.
+2. Run `python manage.py dj_queue_health --deep` for queue processes and
+   invariants. Use your deployment platform to confirm that no older application
+   producer remains.
+3. Apply release N migrations once.
+4. Roll application producers and queue processes from N−1 to N.
+5. Run `python manage.py dj_queue_health --deep --require-version <N version>` for
+   queue processes. Use your deployment platform to confirm that no N−1
+   application producer remains.
+
+Each registered queue process stores its exact `dj_queue` version and rollout
+protocol generation. Deep health rejects a missing or incompatible protocol.
+`--require-version` also rejects a live queue process on another package
+version. Application producers do not register process rows, so check those in
+your deployment platform.
+
+A code rollback from N to N−1 keeps the expanded schema in place. Do not reverse
+the database migration during a live rollback. N−2 processes and skipped bridge
+releases are not supported.
+
+Expansion migrations keep one DDL operation per hot table migration so lock
+conflicts can retry safely. Constraints that a supported database cannot add
+online stay deferred until a later activation or contract release.
+
+This contract covers `dj_queue`'s schema and runtime. Jobs can outlive an
+application deployment, so keep your task import paths and accepted argument
+shapes compatible. Use a new task name when a payload change cannot be backward
+compatible.
+
+Maintainers can prove a candidate rollout against two immutable revisions:
+
+```bash
+bin/prerelease.py \
+  --from-ref <release-n-1-ref> \
+  --to-ref <release-n-ref> \
+  --backend postgres \
+  --django '>=6.0,<6.1'
+```
+
+The command calibrates release N−1, applies release N migrations under live
+writes, runs both versions together, drains with release N, and verifies queue
+state and side effects. It rejects revisions that do not publish one shared
+rollout protocol. It writes wheel hashes, one-second metrics, logs, and a result
+manifest under `benchmark-results/`. The **Pre-release migration load** workflow
+runs the database floor and current-version lanes. `--smoke` and custom workload
+profiles keep all validity and stability gates and record performance. Only the
+default ten-minute release profile enforces the X-to-Y performance ratios.
+
 ## Recurring Tasks
 
 `dj_queue` supports both static recurring tasks from settings and dynamic
@@ -419,27 +498,33 @@ Notes:
 
 Tasks can opt into database-backed concurrency limits.
 
-`django.tasks` has no standard way to pass backend-specific options through the
-`@task` decorator, so `dj_queue` reads them as attributes on the wrapped function:
+Use `dj_queue.api.concurrency` with Django's `@task` decorator:
 
 ```python
 from django.tasks import task
+from dj_queue.api import concurrency
+
 
 @task
+@concurrency(
+  key="account:{account_id}",
+  limit=1,
+  duration=60,
+  on_conflict="block",
+)
 def sync_account(account_id, action):
   return f"{account_id}:{action}"
-
-sync_account.func.concurrency_key = "account:{account_id}"
-sync_account.func.concurrency_limit = 1
-sync_account.func.concurrency_duration = 60
-sync_account.func.on_conflict = "block"
 ```
 
 With this configuration:
 
 - the first matching job can run immediately
 - later jobs for the same key can block until capacity is released
-- `on_conflict = "discard"` turns the same pattern into singleton-style work
+- `on_conflict="discard"` turns the same pattern into singleton-style work
+
+The concurrency key can be a format string or a callable. Both decorator orders
+are supported, but placing `@task` above `@concurrency` keeps backend-specific
+options next to the task function.
 
 Semaphore rows remain shared on the queue database. If you want per-backend
 isolation for a limit, express that in the `concurrency_key` itself rather than
@@ -485,10 +570,13 @@ Operational commands:
 
 ```bash
 python manage.py dj_queue_health
+python manage.py dj_queue_health --deep
 python manage.py dj_queue_health --max-age 120
+python manage.py dj_queue_health --deep --require-version 0.13.0
 python manage.py dj_queue_prune --older-than 86400
 python manage.py dj_queue_prune --failed-older-than 604800
 python manage.py dj_queue_prune --recurring-older-than 2592000
+python manage.py dj_queue_prune --batch-size 500
 python manage.py dj_queue_prune --task-path myapp.tasks.cleanup
 python manage.py dj_queue_prune --task-key nightly_cleanup
 python manage.py dj_queue_postgres_autovacuum
@@ -496,9 +584,16 @@ python manage.py dj_queue_postgres_autovacuum
 
 The health, prune, and PostgreSQL autovacuum commands accept `--backend` to target a non-default backend alias.
 
+`dj_queue_health` exits with status `1` and prints a reason when no process is
+live. Add `--deep` to check persisted queue invariants and live process rollout
+protocols. Add `--require-version` to require one exact package version across
+all live queue processes.
+
 For `dj_queue_prune`, `--task-path` filters finished and failed job cleanup by
 task import path, while `--task-key` filters recurring execution cleanup by
-recurring task key.
+recurring task key. One invocation deletes at most `--batch-size` rows from
+each retained row type. Run it again when it reports that the batch limit was
+reached.
 
 ## Failed Jobs
 
@@ -570,14 +665,17 @@ Each callback receives the live supervisor or runner instance.
 ```python
 from dj_queue.hooks import on_start, on_worker_start, register_hook
 
+
 @on_start
 def supervisor_started(process):
   print(process.name)
 
+
 @on_worker_start
 def worker_started(process):
   print(process.metadata)
 
+
 @register_hook("scheduler.exit")
 def scheduler_exited(process):
   print(process.name)
@@ -864,6 +962,10 @@ Configuration precedence is explicit:
 - TOML file pointed to by `DJ_QUEUE_CONFIG`
 - Django `TASKS` settings
 
+Unknown option names are rejected in Django settings and in the selected TOML
+overlay, including nested worker, dispatcher, scheduler, and recurring task
+options. The error identifies the exact configuration path and option name.
+
 ### TOML file config
 
 ```bash

{dj_queue-0.13.0 → dj_queue-0.14.0}/dj_queue/admin.py

@@ -6,13 +6,11 @@ from django.contrib import admin, messages
 from django.http import HttpResponseNotAllowed, HttpResponseRedirect
 from django.template.response import TemplateResponse
 from django.urls import path, reverse
+from django.utils import timezone
 from django.utils.html import format_html
 from django.utils.http import url_has_allowed_host_and_scheme
-from django.utils import timezone
 
-from dj_queue import dashboard
-from dj_queue import dashboard_actions
-from dj_queue import observability
+from dj_queue import dashboard, dashboard_actions, observability
 from dj_queue.api import QueueInfo, unschedule_recurring_task
 from dj_queue.db import get_database_alias
 from dj_queue.exceptions import EnqueueError
@@ -495,6 +493,9 @@ class JobAdmin(HiddenSidebarAdminMixin, admin.ModelAdmin):
     "backend_alias",
     "scheduled_at",
     "concurrency_key",
+    "concurrency_limit",
+    "concurrency_duration",
+    "concurrency_on_conflict",
     "finished_at",
     "return_value",
     "created_at",
@@ -964,8 +965,24 @@ class PauseAdmin(HiddenSidebarAdminMixin, admin.ModelAdmin):
 
 @admin.register(Semaphore)
 class SemaphoreAdmin(HiddenSidebarAdminMixin, admin.ModelAdmin):
-  list_display = ("key", "value", "limit", "display_blocked_waiters", "display_expires_at")
-  readonly_fields = ("key", "value", "limit", "expires_at", "created_at", "updated_at")
+  list_display = (
+    "key",
+    "display_active_count",
+    "display_available_count",
+    "limit",
+    "display_blocked_waiters",
+    "display_expires_at",
+  )
+  readonly_fields = (
+    "key",
+    "display_active_count",
+    "display_available_count",
+    "value",
+    "limit",
+    "expires_at",
+    "created_at",
+    "updated_at",
+  )
   search_fields = ("key",)
 
   def get_queryset(self, request):
@@ -975,6 +992,14 @@ class SemaphoreAdmin(HiddenSidebarAdminMixin, admin.ModelAdmin):
       blocked_waiter_count=observability.semaphore_blocked_waiter_count_expression(alias)
     )
 
+  @admin.display(description="active")
+  def display_active_count(self, obj):
+    return obj.occupied_count
+
+  @admin.display(description="available")
+  def display_available_count(self, obj):
+    return obj.available_count
+
   @admin.display(description="blocked waiters", ordering="blocked_waiter_count")
   def display_blocked_waiters(self, obj):
     return obj.blocked_waiter_count

{dj_queue-0.13.0 → dj_queue-0.14.0}/dj_queue/api.py

@@ -1,16 +1,18 @@
+from collections.abc import Callable, Mapping
 from functools import partial
+from typing import Any, Literal, Self, TypeVar
 
 from django.db import transaction
+from django.tasks import Task
 
 from dj_queue import observability
+from dj_queue.operations.claiming import ClaimedJob, claim_ready_jobs
 from dj_queue.operations.jobs import (
-  ClaimedJob,
-  claim_ready_jobs,
   discard_blocked_jobs,
   discard_failed_job,
   discard_failed_jobs,
-  discard_ready_jobs_for_queue,
   discard_ready_jobs,
+  discard_ready_jobs_for_queue,
   discard_scheduled_jobs,
   execute_claimed_job,
   retry_failed_job,
@@ -24,6 +26,7 @@ __all__ = [
   "ClaimedJob",
   "QueueInfo",
   "claim_ready_jobs",
+  "concurrency",
   "discard_blocked_jobs",
   "discard_failed_job",
   "discard_failed_jobs",
@@ -38,15 +41,42 @@ __all__ = [
   "unschedule_recurring_task",
 ]
 
+_Decorated = TypeVar("_Decorated")
+
+
+def concurrency(
+  *,
+  key: str | Callable[..., str],
+  limit: int,
+  duration: int | None = None,
+  on_conflict: Literal["block", "discard"] = "block",
+) -> Callable[[_Decorated], _Decorated]:
+  def decorator(target: _Decorated) -> _Decorated:
+    func = getattr(target, "func", target)
+    func.concurrency_key = key
+    func.concurrency_limit = limit
+    if duration is not None:
+      func.concurrency_duration = duration
+    func.on_conflict = on_conflict
+    return target
+
+  return decorator
+
 
 class QueueInfo:
-  def __init__(self, queue_name, *, backend_alias="default", snapshot=None):
+  def __init__(
+    self,
+    queue_name: str,
+    *,
+    backend_alias: str = "default",
+    snapshot: Mapping[str, Any] | None = None,
+  ) -> None:
     self.queue_name = queue_name
     self.backend_alias = backend_alias
     self._snapshot = snapshot
 
   @property
-  def size(self):
+  def size(self) -> int:
     if self._snapshot is not None:
       return self._snapshot["ready_count"]
     return observability.queue_ready_count(
@@ -55,7 +85,7 @@ class QueueInfo:
     )
 
   @property
-  def latency(self):
+  def latency(self) -> float | None:
     if self._snapshot is not None:
       latency = self._snapshot["latency_seconds"]
       if latency is None and not self._snapshot["paused"]:
@@ -77,7 +107,7 @@ class QueueInfo:
     return 0.0 if latency is None else latency
 
   @property
-  def paused(self):
+  def paused(self) -> bool:
     if self._snapshot is not None:
       return self._snapshot["paused"]
     return observability.queue_is_paused(
@@ -85,15 +115,15 @@ class QueueInfo:
       queue_name=self.queue_name,
     )
 
-  def pause(self):
+  def pause(self) -> None:
     pause_queue(self.queue_name, backend_alias=self.backend_alias)
     self._snapshot = None
 
-  def resume(self):
+  def resume(self) -> None:
     resume_queue(self.queue_name, backend_alias=self.backend_alias)
     self._snapshot = None
 
-  def clear(self, *, batch_size=500):
+  def clear(self, *, batch_size: int = 500) -> int:
     deleted = 0
     while True:
       batch_deleted = discard_ready_jobs_for_queue(
@@ -107,10 +137,15 @@ class QueueInfo:
       deleted += batch_deleted
 
   @classmethod
-  def all(cls, *, backend_alias="default"):
+  def all(cls, *, backend_alias: str = "default") -> list[Self]:
     queue_rows = observability.queue_rows_for_backend(backend_alias=backend_alias)
     return [cls(row["name"], backend_alias=backend_alias, snapshot=row) for row in queue_rows]
 
 
-def enqueue_on_commit(task, *args, using=None, **kwargs):
+def enqueue_on_commit(
+  task: Task,
+  *args: Any,
+  using: str | None = None,
+  **kwargs: Any,
+) -> None:
   transaction.on_commit(partial(task.enqueue, *args, **kwargs), using=using)

{dj_queue-0.13.0 → dj_queue-0.14.0}/dj_queue/apps.py

@@ -1,5 +1,4 @@
-from django.apps import AppConfig
-from django.apps import apps
+from django.apps import AppConfig, apps
 
 
 class DjQueueConfig(AppConfig):