Default sentry_auto_enabling_integrations to False together with lean capture #313

sentry-sdk auto-enables integrations for every installed package it knows: the web frameworks, SQLAlchemy, asyncpg, redis, httpx and others (sentry_sdk/integrations/__init__.py, _AUTO_ENABLING_INTEGRATIONS). auto_enabling_integrations=False turns those off while keeping the default ones (dedupe, excepthook, threading, stdlib, atexit, modules, argv) and lite-bootstrap's own LoggingIntegration. lite-bootstrap does not pass auto_enabling_integrations and has no field for it.

With tracing off, those integrations still start a span and record a breadcrumb for every statement or command they see. Measured on 2026-10-24 on Linux with 2 CPUs: litestar-sqlalchemy-template on its own lock (sentry-sdk 2.70.0, SQLAlchemy 2.0.55, asyncpg) with lite-bootstrap replaced by 705d8a3, Postgres 17 in its own container, Granian 1 worker with uvloop, ab -k -c 32, on GET /api/decks/1/ (one SQL statement), over Sentry off at 480 µs:

The saving is SqlalchemyIntegration: about 64 µs per SQL statement with tracing off. LoggingIntegration accounts for about 5 µs of the earlier gap between lean capture and sentry_default_integrations=False. On FastStream, RedisIntegration adds +28.8 µs per broker.publish (in-process, Redis 8), and auto_enabling_integrations=False brings that to +0.0. On a handler that does no I/O there is nothing to save. With tracing off, MCPIntegration measured at no cost per FastMCP tool call (+99 µs with it disabled against +100 µs); what it adds to events was not checked. The tables and scripts are to be published with #335.

The integration list includes the framework integrations (Litestar, Starlette, FastAPI, MCP). Without lean capture, auto_enabling_integrations=False silently stops request error capture: in-process on a do-nothing handler, Sentry then costs -0.1 µs on Litestar because nothing captures. The default can only change together with #307 and #341. With tracing on, the auto-enabled integrations produce the DB and Redis spans users want, so the default should follow tracing as lean capture does.

Work

• Test first: with only sentry_dsn set, the Sentry client's integrations contain no sqlalchemy, asyncpg, redis or httpx entry while lean capture is on, and a failing request still produces one event. It fails today.
• Add sentry_auto_enabling_integrations: bool | None = None to SentryConfig and pass it as auto_enabling_integrations. None resolves to False when lean capture is on and True when sentry-sdk's framework integration is in use. An explicit value wins; an auto_enabling_integrations in sentry_additional_params still wins through the existing init_params.update.
• On 3.0.0b1, check that the default list still keeps lite-bootstrap's LoggingIntegration (3.0 drops it from the default list, see Support sentry-sdk 3.0 alongside 2.x #306) and that the resolved value behaves the same.
• Docs: the Sentry section of docs/introduction/configuration.md, naming what users lose (SQL, Redis and httpx breadcrumbs on error events, and anything else an auto-enabled integration reports), and the recipe for keeping them: sentry_auto_enabling_integrations=True, or list the wanted integrations in sentry_integrations.

Verify: the new test passes, and the template rerun with lite-bootstrap defaults lands near the auto_enabling_integrations=False row above.

Breaking for services with Sentry and tracing off that rely on breadcrumbs from SQLAlchemy, asyncpg, redis, httpx or another auto-enabled integration: those breadcrumbs stop until they set sentry_auto_enabling_integrations=True.