Supersedes #31. Taking #31 as-is would double every exported span in production. The deployed container has OTEL_EXPORTER_OTLP_ENDPOINT set.

The defect

FastAPI 0.142.0 added native OpenTelemetry (fastapi/fastapi#16403). On lifespan startup, fastapi.telemetry._runtime._configure_from_environment reads OTEL_EXPORTER_OTLP_ENDPOINT. That's the same variable tracing.py uses as its switch. FastAPI then:

• attaches its own BatchSpanProcessor(OTLPSpanExporter) to the TracerProvider that is already installed. Its docstring says it "does not inspect or deduplicate other components' exporters".
• installs SDK MeterProvider and LoggerProvider with OTLP exporters.

#31's CI was green because no test looks at exporter count.

Measured

I ran create_app with tracing on against a local OTLP capture server, made 5 requests and flushed:

Fix

FastAPI(..., telemetry={"auto_configure": False}). Before 0.142 the keyword lands in app.extra and does nothing, so the declared fastapi>=0.115,<1 range stays. I checked this on 0.141.1. Native request spans are already suppressed, because FastAPI detects the contrib FastAPIInstrumentor. Duplicate export is the only problem.

Test

TestFastAPIDoesNotExportOnItsOwn sets the endpoint in the real environment, which is what both create_app and FastAPI read, and runs lifespan. It then asserts exactly one span processor and no SDK meter or logger provider. It resets OTel's one-shot globals and FastAPI's _configured registry, so the test can't pass vacuously against an earlier test's provider.

• With the fix removed (mutant): fails at the span-processor assertion.
• On FastAPI 0.141.1: skipped, with the reason "FastAPI < 0.142 has no native telemetry". 669 passed.
• On 0.142.2 (lock): 670 passed. ruff check and format are clean.

Lock

fastapi 0.141.1 → 0.142.2. opentelemetry-api becomes a base dependency of fastapi. That's the API only, with no SDK or exporter.

Refs vikunja#746 (0.x minor treated as a major), vikunja#1031.

🤖 Generated with Claude Code