django-lambda-tasks 0.10.0__tar.gz → 0.11.1__tar.gz

{django_lambda_tasks-0.10.0 → django_lambda_tasks-0.11.1}/.github/workflows/ci.yml

@@ -53,3 +53,35 @@ jobs:
       - name: Run tests
         run: |
           uv run pytest --cov-branch --cov-report term-missing --cov=tests/ --cov=lambda_tasks/
+
+  sentry-prerelease:
+    # Exercise the Sentry integration against the latest 3.x pre-release of
+    # sentry-sdk (stream mode). The committed dev dependency is pinned to the
+    # stable 2.x line; this job overrides it at runtime via `uv run --with`
+    # without touching pyproject.toml, so regressions in the 3.x API are caught
+    # before the SDK goes stable.
+    runs-on: ubuntu-latest
+    services:
+      postgres:
+        image: postgres:17
+        env:
+          POSTGRES_DB: lambda_tasks_test
+          POSTGRES_USER: postgres
+          POSTGRES_PASSWORD: postgres
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd "pg_isready -U postgres"
+          --health-interval 10s
+          --health-timeout 5s
+          --health-retries 5
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+      - name: Install uv and set the python version
+        uses: astral-sh/setup-uv@68559e99cc807c1eb7e9238fd43a15bba460eec2 # v10.3.3
+        with:
+          python-version: '3.14'
+      - name: Run tests against the latest sentry-sdk 3.x pre-release
+        run: |
+          uv run --prerelease=allow --with "sentry-sdk>=3.0.0b1" \
+            pytest --cov-branch --cov-report term-missing --cov=tests/ --cov=lambda_tasks/

{django_lambda_tasks-0.10.0 → django_lambda_tasks-0.11.1}/.kiro/steering/product.md

@@ -127,7 +127,7 @@ class SQSLambdaTaskMessage(BaseModel):
 
 ## Execution
 
-`SQSLambdaTaskMessage.execute_immediately(*, message_id: str)` in `models.py`:
+`SQSLambdaTaskMessage.execute_immediately(*, message_id: str)` in `models.py` sets the `task_logger` `message_id` and enters `task_scope(...)` (Sentry transaction name + tags), then delegates the run to the private `_run(*, message_id)` method which:
 1. Checks for an existing `TaskRecord` with the same `pk` (`message_id`) via `get_or_create`
 2. If a record already exists (any status), logs and returns immediately — duplicate deliveries are silently skipped
 3. Resolves timeouts: decorator default → settings defaults (soft=270s, hard=300s), validated against queue max (900 for SQS, 3600 for Batch)
@@ -313,6 +313,32 @@ def my_task(*, user_id: int) -> None:
 
 `task_logger` is a `LoggerAdapter` wrapping the `lambda_tasks.task` logger. The executor sets the `message_id` before each task runs and clears it in a `finally` block. Using your own `logging.getLogger(__name__)` is fine — those records just won't carry the prefix.
 
+## Sentry
+
+The library does not call `sentry_sdk.init(...)` — the host application owns Sentry setup (typically `DjangoIntegration` + `AwsLambdaIntegration`). The problem those integrations leave is attribution: on Lambda, `AwsLambdaIntegration` names every event's transaction after the Lambda function, so all tasks look alike; on AWS Batch there is no request and no Lambda integration, so the transaction/URL are `"--"`. Either way you cannot tell which task ran or raised.
+
+`lambda_tasks.sentry.task_scope(*, task_name, message_id, n_retries)` fixes this. `execute_immediately` wraps the task body in it, which — when a Sentry client is active — opens an isolated `sentry_sdk.new_scope()` and traces the task. Trace shape depends on whether a trace is already active:
+
+- **Lambda** — `AwsLambdaIntegration` already started an invocation transaction, so the task is traced as a **child span** of it (not a second transaction). This is deliberate: a nested *transaction* per task inherited (rather than independently re-rolled) the invocation's sampling decision, doubling transaction volume and defeating `traces_sample_rate`. A child span is sent only if its parent is sampled, so sampling is respected. `_start_task_root` picks child-vs-root by checking `sentry_sdk.get_current_scope().transaction` (2.x only; on 3.0 `start_span` is automatically root-or-child).
+- **Batch** (nothing active) — the task starts its **own root transaction** so it is still traced.
+
+It records, both on the span and as scope tags:
+
+- `lambda_task` = fully-qualified task name (e.g. `myapp.tasks.my_task`) — also the task span's name
+- `lambda_task.message_id` = the `TaskRecord` primary key
+- `lambda_task.n_retries` = the retry counter
+- `lambda_task.runtime` = the execution environment, from the AWS environment: `AWS_LAMBDA_FUNCTION_NAME` on Lambda or `AWS_BATCH_JQ_NAME` (Batch job queue name); omitted when neither is present
+
+`task_scope` deliberately does **not** call `scope.set_transaction_name(task_name)`: on Lambda that would rename the shared invocation transaction (fighting across sibling records in a batch) and, on SDK 3.0 stream mode, corrupt the root-segment naming. Error attribution relies on the `lambda_task` **tag** instead, which is reliable on both SDKs and independent of sampling.
+
+**Reporting task failures:** the executor catches task exceptions (recording `FAILED` and not re-raising), so `lambda_tasks.sentry.capture_task_exception()` is called on the two **terminal** failure branches in `models.py` (plain failure and max-retries-exceeded) to report the error via `sentry_sdk.capture_exception()`. This is essential on 3.0, where a merely-caught exception produces no error event. The **retry** branch deliberately does not capture — transient, to-be-re-enqueued failures would flood Sentry; only terminal failures are reported.
+
+**Error-level log forwarding:** on sentry-sdk 2.x, `LoggingIntegration` defaulted to `event_level=ERROR`, so `task_logger.error(...)` became Sentry events automatically. On 3.0 the default is `None`, so hosts that want error logs reported must configure `LoggingIntegration(event_level=logging.ERROR)` explicitly (the example app does this). This is a host-init concern, not something the library sets.
+
+**SDK version compatibility:** `task_scope` is future-proof across the sentry-sdk 2.x→3.0 boundary and verified against both 2.74 and 3.0.0b4. On 2.x it uses `start_transaction` + `set_tag` for a root and `start_span` for a child; on 3.0 (stream mode) `start_span` is both root and child and metadata is attached via `set_attribute`. The correct API is detected at runtime via `hasattr`, so no code change is needed when the host upgrades the SDK.
+
+`task_scope` and `capture_task_exception` are no-ops when `sentry_sdk` is not installed or no client is initialised, so Sentry is not a dependency of the library. `sentry-sdk` is a dev dependency only (pinned `>=2,<3`), for the test suite. No custom Sentry integration is needed — per-task tracing at the one execution entry point covers both Lambda and Batch.
+
 ## Built-in Tasks
 
 `lambda_tasks.tasks` provides maintenance tasks that ship with the library:

{django_lambda_tasks-0.10.0 → django_lambda_tasks-0.11.1}/.kiro/steering/structure.md

@@ -16,6 +16,7 @@ django-lambda-tasks/
 │   ├── decorators.py           # LambdaTaskWrapper, @lambda_task
 │   ├── handler.py              # AWS Lambda entry point + AWS Batch container entry point (main)
 │   ├── logging.py              # task_logger — invocation-scoped LoggerAdapter
+│   ├── sentry.py               # task_scope + capture_task_exception — per-task trace, tags, failure reporting
 │   ├── models.py               # TaskRecord, SQSLambdaTaskMessage, SQSLambdaTask
 │   ├── settings.py             # LambdaTasksSettings, constants, queue type helpers
 │   ├── secret_loader.py        # Resolves LAMBDA_TASKS_SECRET_* env vars at cold start
@@ -41,12 +42,13 @@ django-lambda-tasks/
 ## Module Responsibilities
 
 - `decorators.py` — defines `LambdaTaskWrapper` and `@lambda_task` decorator factory; enforces kwargs-only at decoration time; validates timeouts (> 0, soft < hard) at decoration time; upper-bound timeout validation deferred to execution time based on queue type
-- `models.py` — `TaskRecord` (Django ORM), `SQSLambdaTaskMessage` (Pydantic, SQS schema + execution logic), `SQSLambdaTask` (Pydantic, holds message + routing; `_execute()` inspects queue config to publish to SQS, submit to Batch via `submit_batch_job`, execute eagerly, or submit to the local process pool; `execute_on_commit()` registers `_execute` with `transaction.on_commit`)
+- `models.py` — `TaskRecord` (Django ORM), `SQSLambdaTaskMessage` (Pydantic, SQS schema + execution logic; `execute_immediately` owns the logging + Sentry context and delegates the run to a private `_run` method), `SQSLambdaTask` (Pydantic, holds message + routing; `_execute()` inspects queue config to publish to SQS, submit to Batch via `submit_batch_job`, execute eagerly, or submit to the local process pool; `execute_on_commit()` registers `_execute` with `transaction.on_commit`)
 - `local_executor.py` — `ProcessPoolExecutor`-based async local execution; `get_pool()` lazily creates a module-level pool; `submit_task()` fire-and-forget submission; `_execute_in_worker()` deserializes and runs the task in a child process; `_pool_initializer()` calls `django.setup()` per worker (and sets `SIGINT` to `SIG_IGN` so workers ignore Ctrl+C); `_install_shutdown_handlers()` installs main-thread `SIGINT`/`SIGTERM` handlers that release the pool before chaining to the previous handler
 - `handler.py` — Lambda entry point (`handler(event, context)`); cold-start init (memory limit → temporary log handler → `resolve_environment()` → `resolve_secrets_into_env()` → handler removed → conditional `django.setup()`) runs inside the handler on first invocation, guarded by `_cold_start_done` sentinel; calls `db.close_old_connections()` before each SQS record to handle stale connections on warm starts; processes SQS records independently; returns `batchItemFailures`. Also provides `main()` as the AWS Batch container entry point (`python -m lambda_tasks.handler`) — reads `LAMBDA_TASKS_MESSAGE` env var, constructs a synthetic SQS event, and delegates to `handler()`
 - `environment_loader.py` — loads env vars from a Secrets Manager secret at cold start; validates flat JSON format; idempotent via `_loaded` sentinel
 - `secret_loader.py` — resolves `LAMBDA_TASKS_SECRET_*` env vars from Secrets Manager before Django starts; validates format, detects conflicts, batches API calls; idempotent via `_loaded` sentinel
 - `logging.py` — `task_logger` singleton; `message_id` set/cleared around each task execution
+- `sentry.py` — `task_scope` context manager + `capture_task_exception` helper. `task_scope` opens an isolated `new_scope` and traces the task: a **child span** of the invocation transaction on Lambda (where `AwsLambdaIntegration` already started one), or its **own root transaction** on Batch (nothing active). The child-span-on-Lambda behaviour avoids a second per-task transaction that would double trace volume and defeat `traces_sample_rate`. Records `lambda_task` / `lambda_task.message_id` / `lambda_task.n_retries` / `lambda_task.runtime` as span metadata and scope tags (runtime read from `AWS_LAMBDA_FUNCTION_NAME` or `AWS_BATCH_JQ_NAME`). Deliberately does not call `set_transaction_name` (would rename the shared invocation transaction and break 3.0 segment naming); error attribution rides on the `lambda_task` tag. `capture_task_exception` calls `sentry_sdk.capture_exception()` and is invoked on the terminal failure branches in `models.py` (plain failure + max-retries), since the executor catches exceptions without re-raising and 3.0 does not auto-report caught exceptions; the retry branch does not capture. Future-proof across the SDK 2.x→3.0 boundary (verified against 2.74 and 3.0.0b4): `start_transaction`/`set_tag`/child `start_span` on 2.x, `start_span`/`set_attribute` on 3.0, detected at runtime via `hasattr`. No-op when `sentry_sdk` is absent or uninitialised (`sentry-sdk` is a dev dependency only, pinned `>=2,<3`). Wrapped around the task body in `SQSLambdaTaskMessage.execute_immediately`. Note: `logger.error → Sentry event` needs `LoggingIntegration(event_level=logging.ERROR)` in the host init on 3.0 (default on 2.x); a host concern, demonstrated in the example app
 - `settings.py` — constants (`MAX_DELAY`, `MAX_TIMEOUT`, `MAX_BATCH_TIMEOUT`); `_is_sqs_queue()` and `_is_batch_queue()` helpers; `LambdaTasksSettings` instantiated fresh per use (reads live Django settings); `queue_max_timeout()` method returns 900 or 3600 based on queue type
 - `admin.py` — Django admin registration for `TaskRecord`
 - `apps.py` — Django `AppConfig`; `ready()` imports `checks` to register deployment checks and installs the local-executor shutdown signal handlers when `LOCAL_WORKERS > 0`

{django_lambda_tasks-0.10.0 → django_lambda_tasks-0.11.1}/.kiro/steering/tech.md

@@ -23,6 +23,7 @@ inclusion: always
 |---|---|---|
 | `pytest` | `>= 9.0.2` | Test runner |
 | `hypothesis` | present | Property-based testing (`.hypothesis/` directory exists) |
+| `sentry-sdk` | `>=2,<3` | Testing the Sentry integration (`task_scope`, `capture_task_exception`); verified against 2.74 and 3.0.0b4. Not a runtime dependency |
 
 ## Package Manager
 

{django_lambda_tasks-0.10.0 → django_lambda_tasks-0.11.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: django-lambda-tasks
-Version: 0.10.0
+Version: 0.11.1
 Summary: Run async tasks in a lambda function
 Requires-Python: >=3.11
 Requires-Dist: awslambdaric
@@ -444,6 +444,57 @@ fields @timestamp, @message
 | sort @timestamp asc
 ```
 
+### Sentry
+
+If your application uses Sentry, task errors are automatically attributed to the task that raised them. Without this, Sentry's `AwsLambdaIntegration` names every event's transaction after the Lambda function (so all tasks look the same), and on AWS Batch there is no transaction at all (it shows as `"--"`) — so you cannot tell which task failed.
+
+Keep your existing `sentry_sdk.init(...)`. On **sentry-sdk 2.x** no change is needed. On **sentry-sdk 3.0+** one option changed default and must be set explicitly if you want error-level logs reported (see below):
+
+```python
+import logging
+from sentry_sdk.integrations.logging import LoggingIntegration
+
+sentry_sdk.init(
+    dsn=SENTRY_DSN,
+    integrations=[
+        DjangoIntegration(),
+        AwsLambdaIntegration(),
+        # Only needed on sentry-sdk 3.0+: its default event_level is None, so
+        # logger.error(...) no longer becomes a Sentry event. On 2.x this was
+        # the default and setting it is harmless.
+        LoggingIntegration(event_level=logging.ERROR),
+    ],
+    traces_sample_rate=0.1,
+)
+```
+
+#### What the library does per task
+
+When a task runs, `execute_immediately()` opens an isolated Sentry scope and traces the task:
+
+- **On Lambda**, the task is traced as a **child span** of the invocation transaction that `AwsLambdaIntegration` already started — not a second transaction. This keeps task tracing from doubling your transaction volume and respects `traces_sample_rate`.
+- **On Batch** (no Lambda integration, nothing active), the task starts **its own root transaction** so it is still traced.
+
+Either way it records, as both span metadata and scope tags:
+
+- `lambda_task` — the fully-qualified task name (e.g. `myapp.tasks.send_welcome_email`). This is also the task span's name.
+- `lambda_task.message_id`, `lambda_task.n_retries`
+- `lambda_task.runtime` — the execution environment, from the AWS environment: `AWS_LAMBDA_FUNCTION_NAME` on Lambda or `AWS_BATCH_JQ_NAME` (the Batch job queue name) on Batch. Omitted when neither is set (local/eager).
+
+Error attribution relies on the `lambda_task` **tag**, not on the transaction name, so it is reliable even when the trace is not sampled and regardless of whether the task ran as a child span (Lambda) or a root (Batch).
+
+#### Task failures are reported
+
+The executor catches a failing task's exception (recording a `FAILED` `TaskRecord`) rather than re-raising it. So the library calls `sentry_sdk.capture_exception()` itself on the **terminal failure paths** — a plain failure and max-retries-exceeded — to report the error to Sentry. This is essential on 3.0, where a merely-caught exception produces no error event at all.
+
+Transient, retryable failures (a task that will be re-enqueued) are **not** reported, to avoid flooding Sentry on every retry; only the final, terminal failure is captured.
+
+#### SDK version compatibility
+
+The integration is future-proof across the sentry-sdk 2.x→3.0 boundary and verified against both 2.74 and 3.0.0b4. It uses `start_transaction`/`set_tag` on 2.x and `start_span`/`set_attribute` on 3.0 (stream mode), chosen automatically at runtime — no change needed when you upgrade.
+
+`sentry_sdk` is not a dependency of this library — if it is not installed or not initialised, all of the above is a silent no-op.
+
 ---
 
 ## Automatic retries

{django_lambda_tasks-0.10.0 → django_lambda_tasks-0.11.1}/README.md

@@ -432,6 +432,57 @@ fields @timestamp, @message
 | sort @timestamp asc
 ```
 
+### Sentry
+
+If your application uses Sentry, task errors are automatically attributed to the task that raised them. Without this, Sentry's `AwsLambdaIntegration` names every event's transaction after the Lambda function (so all tasks look the same), and on AWS Batch there is no transaction at all (it shows as `"--"`) — so you cannot tell which task failed.
+
+Keep your existing `sentry_sdk.init(...)`. On **sentry-sdk 2.x** no change is needed. On **sentry-sdk 3.0+** one option changed default and must be set explicitly if you want error-level logs reported (see below):
+
+```python
+import logging
+from sentry_sdk.integrations.logging import LoggingIntegration
+
+sentry_sdk.init(
+    dsn=SENTRY_DSN,
+    integrations=[
+        DjangoIntegration(),
+        AwsLambdaIntegration(),
+        # Only needed on sentry-sdk 3.0+: its default event_level is None, so
+        # logger.error(...) no longer becomes a Sentry event. On 2.x this was
+        # the default and setting it is harmless.
+        LoggingIntegration(event_level=logging.ERROR),
+    ],
+    traces_sample_rate=0.1,
+)
+```
+
+#### What the library does per task
+
+When a task runs, `execute_immediately()` opens an isolated Sentry scope and traces the task:
+
+- **On Lambda**, the task is traced as a **child span** of the invocation transaction that `AwsLambdaIntegration` already started — not a second transaction. This keeps task tracing from doubling your transaction volume and respects `traces_sample_rate`.
+- **On Batch** (no Lambda integration, nothing active), the task starts **its own root transaction** so it is still traced.
+
+Either way it records, as both span metadata and scope tags:
+
+- `lambda_task` — the fully-qualified task name (e.g. `myapp.tasks.send_welcome_email`). This is also the task span's name.
+- `lambda_task.message_id`, `lambda_task.n_retries`
+- `lambda_task.runtime` — the execution environment, from the AWS environment: `AWS_LAMBDA_FUNCTION_NAME` on Lambda or `AWS_BATCH_JQ_NAME` (the Batch job queue name) on Batch. Omitted when neither is set (local/eager).
+
+Error attribution relies on the `lambda_task` **tag**, not on the transaction name, so it is reliable even when the trace is not sampled and regardless of whether the task ran as a child span (Lambda) or a root (Batch).
+
+#### Task failures are reported
+
+The executor catches a failing task's exception (recording a `FAILED` `TaskRecord`) rather than re-raising it. So the library calls `sentry_sdk.capture_exception()` itself on the **terminal failure paths** — a plain failure and max-retries-exceeded — to report the error to Sentry. This is essential on 3.0, where a merely-caught exception produces no error event at all.
+
+Transient, retryable failures (a task that will be re-enqueued) are **not** reported, to avoid flooding Sentry on every retry; only the final, terminal failure is captured.
+
+#### SDK version compatibility
+
+The integration is future-proof across the sentry-sdk 2.x→3.0 boundary and verified against both 2.74 and 3.0.0b4. It uses `start_transaction`/`set_tag` on 2.x and `start_span`/`set_attribute` on 3.0 (stream mode), chosen automatically at runtime — no change needed when you upgrade.
+
+`sentry_sdk` is not a dependency of this library — if it is not installed or not initialised, all of the above is a silent no-op.
+
 ---
 
 ## Automatic retries

django_lambda_tasks-0.11.1/example/example_app/tasks.py

@@ -0,0 +1,31 @@
+from time import sleep
+
+from lambda_tasks.decorators import lambda_task
+from lambda_tasks.logging import task_logger
+
+
+@lambda_task()
+def greet(*, name: str) -> str:
+    """A successful task — produces one per-task Sentry transaction named
+    ``example_app.tasks.greet``."""
+    task_logger.info(f"Running greet with: {name=}")
+
+    for ii in range(3):
+        task_logger.info(f"Sleeping: {ii=}")
+        sleep(1)
+
+    try:
+        raise RuntimeError("testing")
+    except Exception:
+        task_logger.error("Raising", exc_info=True)
+
+    return f"Hello, {name}!"
+
+
+@lambda_task()
+def boom(*, name: str) -> str:
+    """A failing task — the executor records it as a FAILED TaskRecord and the
+    error is reported to Sentry attributed to ``example_app.tasks.boom`` (not
+    the Lambda function name), inside its own per-task trace."""
+    task_logger.info(f"Running boom with: {name=}")
+    raise RuntimeError(f"boom for {name}")

django_lambda_tasks-0.11.1/example/example_app/urls.py

@@ -0,0 +1,7 @@
+from django.urls import path
+from example_app.views import trigger, trigger_error
+
+urlpatterns = [
+    path("trigger/", trigger),
+    path("trigger-error/", trigger_error),
+]

django_lambda_tasks-0.11.1/example/example_app/views.py

@@ -0,0 +1,17 @@
+from django.http import HttpRequest, HttpResponse
+from example_app.tasks import boom, greet
+
+
+def trigger(request: HttpRequest) -> HttpResponse:
+    """Enqueue the successful task — produces a per-task Sentry transaction."""
+    name = request.GET.get("name", "world")
+    greet.execute_on_commit(name=name)
+    return HttpResponse(f"greet task triggered for: {name}")
+
+
+def trigger_error(request: HttpRequest) -> HttpResponse:
+    """Enqueue the failing task — produces a Sentry error attributed to the
+    task name, inside its own per-task trace."""
+    name = request.GET.get("name", "world")
+    boom.execute_on_commit(name=name)
+    return HttpResponse(f"boom task triggered for: {name}")

django_lambda_tasks-0.11.1/example/example_project/sentry.py

@@ -0,0 +1,50 @@
+"""Optional Sentry initialisation for the example app.
+
+Demonstrates how a host application wires Sentry so that
+``django-lambda-tasks`` can attribute per-task traces and errors. This mirrors
+a typical production ``sentry_sdk.init(...)`` (Django + AWS Lambda integrations
+and tracing), but is driven entirely by environment variables so the example
+runs with or without Sentry configured.
+
+``init_sentry()`` is called from ``settings.py`` at import time. Because the
+local process-pool workers call ``django.setup()`` (which imports settings) in
+each child process, this runs in the web process *and* in every task worker —
+which is exactly what is needed for the per-task trace to be captured where the
+task actually executes.
+"""
+
+import logging
+import os
+
+
+def init_sentry() -> None:
+    """Initialise Sentry if ``SENTRY_DSN`` is set; otherwise do nothing.
+
+    Idempotent enough for the example's purposes: ``sentry_sdk.init`` is safe to
+    call once per process, and this is only invoked from settings import.
+    """
+    dsn = os.environ.get("SENTRY_DSN")
+    if not dsn:
+        return
+
+    import sentry_sdk
+    from sentry_sdk.integrations.aws_lambda import AwsLambdaIntegration
+    from sentry_sdk.integrations.django import DjangoIntegration
+    from sentry_sdk.integrations.logging import LoggingIntegration
+
+    sentry_sdk.init(
+        dsn=dsn,
+        integrations=[
+            DjangoIntegration(),
+            AwsLambdaIntegration(),
+            # On sentry-sdk 2.x the logging integration defaulted to
+            # event_level=ERROR, so logger.error(...) calls (e.g. task_logger)
+            # became Sentry events automatically. On 3.0 the default is None, so
+            # error logs no longer surface as events. Set it explicitly so
+            # task_logger.error output appears in Sentry on both SDK versions.
+            LoggingIntegration(event_level=logging.ERROR),
+        ],
+        # Sample every transaction so the per-task trace is always sent while
+        # you are testing. Lower this in a real deployment.
+        traces_sample_rate=float(os.environ.get("SENTRY_TRACES_SAMPLE_RATE", "1.0")),
+    )

{django_lambda_tasks-0.10.0 → django_lambda_tasks-0.11.1}/example/example_project/settings.py

@@ -88,3 +88,10 @@ LOGGING = {
         "level": "INFO",
     },
 }
+
+# Optional Sentry integration — set SENTRY_DSN to enable. Initialised here (at
+# settings import) so it also runs inside each local process-pool worker, which
+# imports settings via django.setup(). See example_project/sentry.py.
+from example_project.sentry import init_sentry  # noqa: E402
+
+init_sentry()