Upgrade FastAPI to 0.141.1 and the OpenTelemetry stack to 0.65b0/1.44.0

[claude]

Requested by Damien Garros, Patrick Ogenstad · Slack thread

Why

This is the enabling dependency bump for native FastAPI frontend serving. FastAPI 0.137+ restructured router.routes, and the OpenTelemetry instrumentation we pin (older than 0.64b0) breaks against that structure. The frontend-serving refactor cannot land until both FastAPI and the OpenTelemetry stack move up together, so this PR does the coordinated version bump on its own.

Goal: land the version bump in isolation so the runtime-behavior change can be reviewed separately on top of it.

Non-goals: no runtime/behavior change. The existing frontend serving (hand-rolled /assets + /favicons static mounts and the Jinja single-page-app catch-all) is left exactly as it is on develop.

Refs #10097

What changed

Before

• FastAPI 0.136.3
• OpenTelemetry core (api / sdk / exporters / proto) 1.39.0
• OpenTelemetry contrib (instrumentation packages, semantic-conventions, util-http) 0.60b0

After

• FastAPI 0.141.1
• OpenTelemetry core 1.44.0
• OpenTelemetry contrib 0.65b0

Only pyproject.toml, uv.lock, and a changelog fragment change. No application code changes; no runtime behavior change. schema/openapi.json regenerates with no diff.

The lockfile update is: FastAPI bumped, 12 OpenTelemetry packages bumped, and the now-unneeded transitive deps importlib-metadata and zipp removed (OpenTelemetry 1.44 dropped its importlib-metadata dependency).

This is a coordinated OpenTelemetry-stack bump, not just a FastAPI bump. Core 1.39 → 1.44 and contrib 0.60b0 → 0.65b0 must ship together with the FastAPI bump: FastAPI ≥ 0.137 restructured router.routes, which breaks OpenTelemetry instrumentation older than 0.64b0. Bumping FastAPI without the OpenTelemetry stack would leave instrumentation broken.

How to review

The diff is mechanical (pins + lock), but the risk is in telemetry, which has no automated test coverage in this repo. A reviewer should:

1. Smoke-test trace export to an OTLP collector on both transports — gRPC (opentelemetry-exporter-otlp-proto-grpc) and HTTP/protobuf (opentelemetry-exporter-otlp-proto-http) — and confirm spans still arrive.
2. Confirm OTEL_SEMCONV_STABILITY_OPT_IN stays unset. The HTTP semantic-convention default is unchanged across this bump; leaving the opt-in unset keeps the current attribute names, so it should not be set as part of this change.

Watch-items (silent behavior deltas in the OpenTelemetry bump)

• process.command_args / process.command_line resource attributes are dropped in core 1.44 — if any dashboard/alert keys off those resource attributes, it will go blank.
• Log-batch flush default changed 5s → 1s — more frequent export flushes; benign, but worth knowing when reading collector traffic.

How to test

uv sync --all-groups
uv run python -c "import infrahub.server"
uv run pytest backend/tests/unit -q -k "server or api" --co

Import, collection, and a representative unit module (backend/tests/unit/webhook/test_classifier.py, 18 passed) all pass on the bumped stack. uv run invoke schema.generate-jsonschema produces no diff.

Impact & rollout

• Backward compatibility: no API/behavior change; frontend serving unchanged.
• Config/env changes: none. OTEL_SEMCONV_STABILITY_OPT_IN intentionally stays unset.
• Deployment notes: safe to deploy on its own; it is the base for the stacked frontend-serving PR (Serve frontend via FastAPI native app.frontend() #10099).

Checklist

• Tests added/updated (n/a — dependency bump, no behavior change; existing suite validated)
• Changelog entry added
• External docs updated (n/a)
• Internal .md docs updated (n/a)
• I have reviewed AI generated content

---

Generated by Claude Code

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing claude/fastapi-otel-upgrade (c76bfc0) with develop (cb1c605)}