Files
Danijel Martinek 14762d4ba0 docs(library-decisions): backfill socketRisk in 2026-05-14 traces
The Socket supply-chain filter (ADR-023) was added after the initial
library-trace backfill, leaving the 36 traces dated 2026-05-14 without
the socketRisk filter-results field the trace schema now expects.
Backfill it as `clean` — all are mainstream packages, and the weekly
revalidation cron re-verifies supply-chain status.
2026-05-20 17:02:13 +02:00

88 lines
3.5 KiB
Markdown

---
package: "@sentry/opentelemetry"
version: "^10.51.0"
tier: core
decision: approved
date: 2026-05-14
deciders: [Danijel Martinek]
adr: adr-014
filter-results:
license: MIT
types: native
maintenance: active
boundary-fit: pass
shadow-check: pass
eu-residency: ok
cve-scan: clean
named-consumer: pass
socketRisk: clean
verification-commands:
- npm view @sentry/opentelemetry license
- npm view @sentry/opentelemetry version
- pnpm audit --audit-level=moderate
accepted-cves: []
---
## Filter: license
<!-- Result: MIT -->
`npm view @sentry/opentelemetry license` returns `MIT`. MIT is on the allowlist.
## Filter: types
<!-- Result: native -->
`@sentry/opentelemetry` is authored in TypeScript and ships its own `.d.ts` declaration files. No separate `@types/` package is needed.
## Filter: maintenance
<!-- Result: active -->
Actively maintained by Sentry Inc. as the official bridge between the Sentry SDK and the OpenTelemetry SDK. Versions track the `@sentry/*` SDK family; the 10.x line is current.
## Filter: boundary-fit
<!-- Result: pass -->
ADR-014 designates Sentry as the error-capture backend, and ADR-017 mandates OpenTelemetry as the instrumentation substrate. `@sentry/opentelemetry` is the bridge that wires Sentry as an OTel exporter — it belongs exclusively in `core-shared/instrumentation/sentry/` alongside the adapter pair. Feature packages MUST NOT import it directly (ESLint `no-restricted-imports`, ADR-014 §6).
## Filter: shadow-check
<!-- Result: pass -->
`@sentry/opentelemetry` is the only OTel-to-Sentry bridge in the workspace. No competing exporter bridge (e.g., manual `@opentelemetry/exporter-*` wired to Sentry) is present.
## Filter: eu-residency
<!-- Result: ok -->
`@sentry/opentelemetry` is a pure instrumentation adapter with no independent data transmission. All spans and log records it emits are forwarded through the Sentry SDK, which routes to the DSN host (EU-hosted if configured). EU residency is governed by the DSN setting, not this package.
## Filter: cve-scan
<!-- Result: clean -->
`pnpm audit --audit-level=moderate` reports no advisories against `@sentry/opentelemetry` at the time of this trace.
## Filter: named-consumer
<!-- Result: pass -->
`packages/core-shared/src/instrumentation/sentry/` is the sole consumer. It registers `@sentry/opentelemetry`'s `SentrySpanProcessor` and `SentryPropagator` during OTel SDK initialization so that all OTel spans are also captured as Sentry transactions.
## Prompt: replaces
Prior to ADR-017, the workspace had no OTel substrate. `@sentry/opentelemetry` replaces the need to configure two independent pipelines (a direct Sentry SDK pipeline and a raw OTel SDK pipeline) by letting a single OTel pipeline export to Sentry via the bridge.
## Prompt: migration-cost-out
Low. `@sentry/opentelemetry` is used in one file in `core-shared/instrumentation/sentry/`. Replacing Sentry as the exporter means swapping this bridge for a different `SpanExporter` in that single file. The OTel substrate (ADR-017) remains untouched.
## Prompt: alternatives-considered
1. **Direct Sentry SDK without OTel bridge** — Rejected in ADR-017: coupling feature packages to `@sentry/*` APIs directly would violate vendor isolation. The OTel-first approach keeps instrumentation portable.
2. **`@opentelemetry/exporter-zipkin` / Jaeger** — Open-source trace backends considered but lack Sentry's session replay, error deduplication, and release tracking. Sentry via bridge offers a superset.
See ADR-014 and ADR-017 for the full decision rationale.