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.
88 lines
3.4 KiB
Markdown
88 lines
3.4 KiB
Markdown
---
|
|
package: "@opentelemetry/sdk-trace-base"
|
|
version: "^1.27.0"
|
|
tier: core
|
|
decision: approved
|
|
date: 2026-05-14
|
|
deciders: [Danijel Martinek]
|
|
adr: adr-017
|
|
filter-results:
|
|
license: Apache-2.0
|
|
types: native
|
|
maintenance: active
|
|
boundary-fit: pass
|
|
shadow-check: pass
|
|
eu-residency: n/a
|
|
cve-scan: clean
|
|
named-consumer: pass
|
|
socketRisk: clean
|
|
verification-commands:
|
|
- npm view @opentelemetry/sdk-trace-base license
|
|
- npm view @opentelemetry/sdk-trace-base version
|
|
- pnpm audit --audit-level=moderate
|
|
accepted-cves: []
|
|
---
|
|
|
|
## Filter: license
|
|
|
|
<!-- Result: Apache-2.0 -->
|
|
|
|
`npm view @opentelemetry/sdk-trace-base license` returns `Apache-2.0`. Apache-2.0 is on the allowlist.
|
|
|
|
## Filter: types
|
|
|
|
<!-- Result: native -->
|
|
|
|
`@opentelemetry/sdk-trace-base` 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 the OpenTelemetry community on the stable 1.x track. The 1.27.x line is current; the tracing specification is stable within CNCF.
|
|
|
|
## Filter: boundary-fit
|
|
|
|
<!-- Result: pass -->
|
|
|
|
ADR-017 §8 restricts `@opentelemetry/sdk-trace-base` to `**/instrumentation/otel/**` and app init paths. `SpanProcessor` and `ReadableSpan` types from this package are used to implement `PiiScrubSpanProcessor` in `core-shared`. `packages/core-audit` also uses `ReadableSpan` for span context in audit records.
|
|
|
|
## Filter: shadow-check
|
|
|
|
<!-- Result: pass -->
|
|
|
|
`@opentelemetry/sdk-trace-base` is the OTel trace SDK foundation. No competing trace SDK is present in the workspace.
|
|
|
|
## Filter: eu-residency
|
|
|
|
<!-- Result: n/a -->
|
|
|
|
`@opentelemetry/sdk-trace-base` is the tracing SDK infrastructure with no independent data transmission. Spans are forwarded through configured processors and exporters. EU residency is governed by the exporter DSN configuration.
|
|
|
|
## Filter: cve-scan
|
|
|
|
<!-- Result: clean -->
|
|
|
|
`pnpm audit --audit-level=moderate` reports no advisories against `@opentelemetry/sdk-trace-base` at the time of this trace.
|
|
|
|
## Filter: named-consumer
|
|
|
|
<!-- Result: pass -->
|
|
|
|
`packages/core-shared/src/instrumentation/otel/pii-scrub-span-processor.ts` implements `SpanProcessor` from `@opentelemetry/sdk-trace-base` to scrub PII attributes before spans reach the Sentry exporter (ADR-017 §7). `packages/core-audit` uses `ReadableSpan` for audit record correlation.
|
|
|
|
## Prompt: replaces
|
|
|
|
The former `SentryTracer` which called Sentry SDK span methods directly. `@opentelemetry/sdk-trace-base` provides the `SpanProcessor` extension point that enables the `PiiScrubSpanProcessor` — a vendor-neutral, pre-export PII scrubbing layer.
|
|
|
|
## Prompt: migration-cost-out
|
|
|
|
Hard. `@opentelemetry/sdk-trace-base` types (`SpanProcessor`, `ReadableSpan`) are used in both `core-shared` PII scrub implementation and `core-audit`. Replacing it means adopting a different span processing abstraction and rewriting both the processor and audit span-context integration.
|
|
|
|
## Prompt: alternatives-considered
|
|
|
|
1. **Sentry `beforeSendTransaction` hook** — Sentry-native PII scrubbing hook. Rejected in ADR-017 §7: runs inside Sentry after OTel conversion; the OTel processor layer runs earlier and is vendor-agnostic, so any future exporter also sees clean data.
|
|
2. **No span processor, rely on Sentry scrubbing rules** — Rejected: Sentry-specific configuration; future exporter additions would need their own scrubbing configured separately.
|
|
|
|
See ADR-017 for the full decision rationale.
|