feat(portal-shell): wire spa-side opentelemetry tracing
CI / commits (pull_request) Successful in 1m9s
CI / scan (pull_request) Successful in 1m21s
CI / check (pull_request) Successful in 1m35s
CI / a11y (pull_request) Successful in 1m25s
CI / perf (pull_request) Successful in 2m38s

Phase 2 of ADR-0012 — closes the loop SPA → BFF → DB. With this
PR a single user action (page load, click, form submit) produces
one trace whose root span is owned by the SPA and whose child
spans cover the BFF request, Postgres queries, and (eventually)
Redis / downstream-API hops.

Runtime libs added (production deps):

- @opentelemetry/sdk-trace-web              browser tracer + provider
- @opentelemetry/exporter-trace-otlp-http   OTLP/HTTP+JSON exporter
- @opentelemetry/instrumentation            auto-instrumentation runtime
- @opentelemetry/instrumentation-fetch      fetch + W3C traceparent propagation
- @opentelemetry/instrumentation-document-load  initial-paint timings
- @opentelemetry/instrumentation-user-interaction  click / keypress / submit

Code:

- apps/portal-shell/src/observability/tracing.ts — WebTracerProvider
  bootstrap. Documents the load-order constraint inline (must be
  the very first import of main.ts, same pattern as the BFF). No
  context-zone package because the workspace is zoneless (per
  ADR-0004); the default StackContextManager covers the
  auto-instrumentation cases.
- main.ts now imports the tracing module as line 1.

CORS plumbing for end-to-end propagation:

- BFF (apps/portal-bff/src/main.ts) calls enableCors with a
  minimal dev allowlist (http://localhost:4200) and explicit
  permission for the W3C traceparent and tracestate headers. The
  full security-grade CORS belongs to phase-2 security ADR; this
  is the strict minimum for the SPA→BFF link to keep the trace
  context across origins.
- OTel Collector (infra/local/otel-collector.yaml) gains a cors
  block on its OTLP/HTTP receiver so the browser's OTLP POST
  clears its own pre-flight.

ADR-0012 §Confirmation: a new "Wired in the SPA foundation PR
(phase 2)" block enumerates what landed here; the carry-over
"Wired as features land" list is updated to drop the SPA-side
SDK item that used to live there and to add a CORS-grade
follow-up note.

Verified locally:
- pnpm exec nx run-many -t lint test build → 8 projects green.
- pnpm audit clean.
- After ./infra/local/dev.sh up observability and nx serve
  portal-shell, opening http://localhost:4200 produces a
  document_load trace in Jaeger with the SPA service.name; a
  manual fetch from DevTools to /api/health on the BFF produces
  a child span on the same trace.
This commit is contained in:
Julien Gautier
2026-05-09 23:18:42 +02:00
parent c3c15585ff
commit 13a12e6591
7 changed files with 255 additions and 36 deletions
@@ -197,15 +197,23 @@ The BFF refuses to start if `LOG_USER_ID_SALT` or `OTEL_SERVICE_NAME` is missing
- `apps/portal-bff/src/health/health.controller.ts` exposes `GET /api/health` (cheap liveness — process metadata only, no DB / Redis / downstream check).
- `apps/portal-bff/.env.example` declares `LOG_LEVEL`, `OTEL_SERVICE_NAME`, `OTEL_SERVICE_VERSION`, `OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_EXPORTER_OTLP_PROTOCOL`, `OTEL_TRACES_SAMPLER` with sensible dev defaults.
**Wired in the SPA foundation PR (phase 2):**
- `apps/portal-shell/src/observability/tracing.ts` initialises a `WebTracerProvider` with the OTLP/HTTP+JSON exporter targeting the same Collector. Auto-instrumentations active: `document-load` (initial-paint timings), `fetch` (every outgoing request, with `traceparent` propagation to the BFF dev origin), `user-interaction` (clicks / keypresses / submits).
- `apps/portal-shell/src/main.ts` `import`s `./observability/tracing` as its very first line — same patching constraint as the BFF.
- BFF `enableCors` allows the SPA dev origin (`http://localhost:4200`) and the `traceparent` / `tracestate` headers, so the W3C trace context survives the cross-origin pre-flight.
- The OTel Collector receiver (`infra/local/otel-collector.yaml`) enables CORS for the SPA dev origin so the browser's OTLP POST clears its own pre-flight.
- Endpoint is hard-coded to the local-dev Collector for v1; per-environment configuration via Angular's `environment.ts` lands when the first non-dev build target is set up.
**Wired as the corresponding features land:**
- CLS keys `session_id`, `user_id_hash`, `audience` — populated by guards/interceptors when ADR-0009 / ADR-0010 land.
- `LOG_USER_ID_SALT` enforced (BFF refuses to start without it) — same trigger.
- Pino `redact` list for PII paths — wired alongside the first DTO that carries a redactable field.
- Custom spans `tracer.startActiveSpan('domain.<verb>', …)` — added per service method that warrants one (creating a row, calling a downstream, etc.).
- SPA-side `@opentelemetry/sdk-trace-web` initialiser, OTLP/HTTP exporter targeting the Collector, `traceparent` header propagated to the BFF — phase-2 PR.
- Custom spans `tracer.startActiveSpan('domain.<verb>', …)` — added per service method that warrants one (creating a row, calling a downstream, etc.). On the SPA side, custom spans across `await` need explicit `context.with(...)` since we are zoneless.
- Integration tests: full SPA → BFF → DB trace with correct parent-child structure; every log line for one request carries the same `trace_id`; redact list strips its targets — wired with the auth + first real screen.
- A separate `/readiness` endpoint that probes Postgres / Redis / OBO cache — wired with the first dependency that has a readiness story to tell.
- Full security-grade CORS (per-environment allowlists, helmet, cookie-session, CSRF) — phase-2 security ADR.
- OTel Collector deployment configuration in the runtime manifest — phase 3b on-prem ADR. The application stays backend-agnostic (any OTLP-capable Collector works).
## Pros and Cons of the Options