FastAPI adapter should fail open when the OTel instrumentor raises per-request

[anth-volk]

Summary

The FastAPI OTel instrumentation incompatibility in #18 (_IncludedRouter has no .path on FastAPI ≥ 0.137) did not just lose telemetry — it 500'd live requests. An AttributeError raised inside OpenTelemetry's own ASGI/FastAPI middleware propagated uncaught and took down every CORS preflight for a downstream consumer (PolicyEngine/policyengine-uk-chat#167).

This violates a core design boundary of this package (docs/engineering/skills/repository-guidance.md):

Observability failures must fail open: record an internal observability error when practical, but do not break the application operation being observed.

Why the current guard is insufficient

FastAPIObservabilityAdapter.instrument_app() wraps the setup-time FastAPIInstrumentor.instrument_app(app) call in try/except, but the crash here happens per-request, inside the OTel OpenTelemetryMiddleware that instrumentation installs — well after setup. So the setup guard never sees it.

Proposal

Make FastAPI instrumentation fail open at request time so an instrumentor defect degrades (drops the span, logs an internal observability failure) instead of surfacing a 500. Options to evaluate:

• Wrap/subclass the OTel ASGI middleware so exceptions from span-detail resolution (e.g. default_span_details / route lookup) are caught and the request continues.
• Or guard our own adapter's interaction points and avoid delegating fragile route introspection to the raw instrumentor.

Add adapter-level tests that assert a raising instrumentor does not change the response status.

References

• Pin opentelemetry-instrumentation-fastapi and -httpx to >=0.64b0 (FastAPI >=0.137 _IncludedRouter crash) #18 (pin fix — the immediate mitigation)
• Production outage: every CORS preflight (OPTIONS) returns 500 — OTel FastAPI instrumentation vs FastAPI >=0.137 policyengine-uk-chat#167 (the production outage)