Sentry Django: uWSGI threads and the shell-verification trap

# Sentry Django: uWSGI threads and the shell-verification trap

## Setup

```python
import sentry_sdk

sentry_sdk.init(
    dsn="___PUBLIC_DSN___",
    send_default_pii=True,  # attaches user id/email/username via django.contrib.auth
    traces_sample_rate=0.1,
)
```

Init in settings or as early as the process starts. The SDK auto-instruments the middleware stack, signals, database queries, Redis commands, and cache access, so most Django apps need no manual spans to get useful traces.

## Trap 1: uWSGI without threads

The docs call this out explicitly: uWSGI does not support threads by default, and the Sentry SDK relies on background threads. Symptoms range from features silently not working to uWSGI workers crashing. The fix is in your uWSGI invocation:

```
uwsgi --enable-threads --py-call-uwsgi-fork-hooks ...
```

Both flags. If you run Django under uWSGI and Sentry behaves erratically, check these before anything else.

## Trap 2: verifying from a shell

Errors triggered from a Python shell like IPython will not trigger error monitoring. The docs verify flow uses a `sentry-debug/` URL view that raises on request. Test through a real HTTP request, not `shell_plus`.

## Data notes

Request data (method, URL, headers, form data, JSON payloads) is attached to all events; raw bodies and multipart file uploads are excluded. Logs from any logger become breadcrumbs via the Logging integration, which is on by default. If breadcrumbs feel noisy, tune `max_breadcrumbs` rather than disabling logging integration outright.