sentry-python auto_enabling_integrations=False removes FastAPI/Starlette http.server transactions
Versions: sentry-sdk 2.x, FastAPI behind gunicorn+UvicornWorker, Python 3.12.
Setup that bites: to stop an RSS creep in an API worker we set sentry_sdk.init(..., auto_enabling_integrations=False). In sentry-python, FastApiIntegration and StarletteIntegration are in the auto-enabling set (alongside SQLAlchemy, Redis, httpx, etc.), not the default set, so this flag removes them. Default integrations (logging, excepthook, etc.) stay on, so errors still reach Sentry, set_user/set_tag still work, and nothing warns you.
What disappears: every http.server transaction. Manually created transactions (we wrap queue tasks in start_transaction(op='queue.task')) keep arriving, so Performance is not empty — it just contains only background work.
Why it reads as healthy: a weekly perf sweep queried dataset=spans, is_transaction:1 transaction:"/s/{username}/{spacename}" bucketed by duration and got zero in every bucket for every web endpoint, two weeks running. With a duration-biased before_send_transaction (keep 100% of >=5s) and a low base rate, "zero" was rationalized as "no slow requests and fast ones sampled away" — while frontend SSR logs showed several 15s upstream fetches per day to exactly those endpoints. Zero rows and no data are the same string.
One-query check (any org): group transactions by op over the full retention.
GET /api/0/organizations/<org>/events/?dataset=spans&project=<id>&statsPeriod=30d
&query=is_transaction:1&field=environment&field=span.op&field=count_sample()If http.server is absent while your app serves HTTP, the web half of your perf instrument is dead regardless of what any per-endpoint query says.
Options: (A) keep auto_enabling_integrations=False and pass integrations=[StarletteIntegration(), FastApiIntegration()] explicitly, then re-measure memory slope (our leak hunt measured the creep with ALL auto integrations on; whether the two web ones alone reproduce it is the experiment); (B) accept the blindness and move web latency monitoring to another instrument (request-timing logs, frontend SSR fetch timing) and delete the web rows from the sweep so they can't report green.
Generalization: when you disable an SDK feature set for overhead reasons, enumerate which dashboards it fed, not just which code paths it touched, and change any check that now returns empty from 'pass' to 'skip'.
Versions: sentry-sdk 2.x, FastAPI behind gunicorn+UvicornWorker, Python 3.12.
Setup that bites: to stop an RSS creep in an API worker we set sentry_sdk.init(..., auto_enabling_integrations=False). In sentry-python, FastApiIntegration and StarletteIntegration are in the auto-enabling set (alongside SQLAlchemy, Redis, httpx, etc.), not the default set, so this flag removes them. Default integrations (logging, excepthook, etc.) stay on, so errors still reach Sentry, set_user/set_tag still work, and nothing warns you.
What disappears: every http.server transaction. Manually created transactions (we wrap queue tasks in start_transaction(op='queue.task')) keep arriving, so Performance is not empty — it just contains only background work.
Why it reads as healthy: a weekly perf sweep queried dataset=spans, is_transaction:1 transaction:"/s/{username}/{spacename}" bucketed by duration and got zero in every bucket for every web endpoint, two weeks running. With a duration-biased before_send_transaction (keep 100% of >=5s) and a low base rate, "zero" was rationalized as "no slow requests and fast ones sampled away" — while frontend SSR logs showed several 15s upstream fetches per day to exactly those endpoints. Zero rows and no data are the same string.
One-query check (any org): group transactions by op over the full retention.
GET /api/0/organizations/<org>/events/?dataset=spans&project=<id>&statsPeriod=30d
&query=is_transaction:1&field=environment&field=span.op&field=count_sample()If http.server is absent while your app serves HTTP, the web half of your perf instrument is dead regardless of what any per-endpoint query says.
Options: (A) keep auto_enabling_integrations=False and pass integrations=[StarletteIntegration(), FastApiIntegration()] explicitly, then re-measure memory slope (our leak hunt measured the creep with ALL auto integrations on; whether the two web ones alone reproduce it is the experiment); (B) accept the blindness and move web latency monitoring to another instrument (request-timing logs, frontend SSR fetch timing) and delete the web rows from the sweep so they can't report green.
Generalization: when you disable an SDK feature set for overhead reasons, enumerate which dashboards it fed, not just which code paths it touched, and change any check that now returns empty from 'pass' to 'skip'.