Repository navigation
fix(v10/opentelemetry): Accept @opentelemetry/api 1.10 Attributes in wrapSamplingDecision - #25633
sentry-junior[bot] wants to merge 2 commits into
Conversation
`@opentelemetry/api` 1.10.0 widened `Attributes` values to `AnyValue`, and a 1.10 copy ignores globals registered by a 1.9 copy. This broke three things on v10: - `wrapSamplingDecision` rejected the `Attributes` a custom sampler receives in `shouldSample`. It now accepts OTel `Attributes`. - Vercel AI v6 integration tests: `ai` pulled its own 1.10 copy into the tmp install, so its spans never reached Sentry. The runner now pins `@opentelemetry/api` in tmp installs to the SDK's version. - node-otel-without-tracing pins 1.9.0 while `@sentry/node` resolved 1.10.0. The app now overrides `@opentelemetry/api` so only one copy is installed. Co-Authored-By: Lukas Stracke <lukas.stracke@sentry.io>
|
the name of this pr should reflect what the pr does, it does not only fix CI it fixes an actual issue I believe? |
sentry-junior
Bot
changed the title
@opentelemetry/api 1.10.0@opentelemetry/api 1.10 Attributes in wrapSamplingDecision
size-limit report 📦
|
| dependencies: additionalDependencies, | ||
| // Packages like `ai` depend on `@opentelemetry/api` themselves. If npm resolves a newer minor than the SDK's | ||
| // copy, the newer copy refuses the globals registered by the older one and the package's spans are dropped. | ||
| overrides: additionalDependencies['@opentelemetry/api'] ? {} : { '@opentelemetry/api': getSdkOtelApiVersion() }, |
There was a problem hiding this comment.
this is weird, can we avoid this. either we bump the installed version locally (while keeping the version as ^1.9.0) or something else, if needed?
There was a problem hiding this comment.
Tried the lockfile route: resolving the monorepo's @opentelemetry/api@^1.9.x to 1.10.0 (ranges unchanged) and dropping this override. It's not a drop-in on v10: 1.10 widens Attributes/AnyValue and the SDK's own build:types starts failing, e.g.
@sentry/opentelemetry:mapStatus.ts,parseSpanDescription.ts(Attributes→SpanAttributes),spanExporter.ts(TimedEvent[],Link[]→SpanLink[])@sentry/deno/@sentry/cloudflare:opentelemetry/tracer.ts(StartSpanOptions)
So bumping locally means a type migration across several packages on v10, which feels out of scope for unblocking CI (and the OTel 2.x SDK packages still declare @opentelemetry/api <1.10.0 as peer).
Alternative that avoids the runner magic: drop the override here and instead pin '@opentelemetry/api': '~1.9.0' explicitly in the Vercel AI v6 tests' additionalDependencies, scoped to the only suites affected (ai@6 is the only additionalDependency pulling its own copy; ai@7 has none). Happy to go with either that or the full 1.10 migration — which do you prefer?
There was a problem hiding this comment.
Do we still need this now that we bumped the node-otel-without-tracing app to ^1.10.0?
There was a problem hiding this comment.
Yes, they're independent:
node-otel-without-tracingis an E2E app. It has its own pnpm install with the packed tarballs, so bumping its range only affects that app.- This override is for the node-integration-tests. They run the SDK from the monorepo's yarn install, which is still on
@opentelemetry/api@1.9.1. Only theai@6tmp install pulls in 1.10.0 here, and that bump doesn't change it.
Locally, span-streaming-v6 fails 6/6 without this change (the main span container has no AI spans) and passes 6/6 with it.
The open question is still mydea's, above: keep this generic pin, or replace it with an explicit '@opentelemetry/api': '~1.9.0' in the Vercel AI v6 tests' additionalDependencies. Bumping the monorepo to 1.10 instead would also break the SDK's build:types.
…1.10.0 Replaces the pnpm override so the app and @sentry/node resolve the same copy.
|
Superseded by #25650 |
2 participants
@opentelemetry/api1.10.0 (published 2026-10-20) widenedAttributesvalues toAnyValue. Custom samplers that follow our documented setup pass theAttributesfromshouldSampletowrapSamplingDecision, and with 1.10 that no longer type-checks againstspanAttributes: SpanAttributes.spanAttributesnow accepts OTelAttributes. The change only widens the type, so it stays compatible with 1.9.The same release also turned v10 CI red. A 1.10 copy of the API treats globals registered by a 1.9 copy as incompatible and falls back to no-op context and tracers. This PR fixes the test setups that hit this:
Root cause
*-custom-samplerE2E apps (3) fail to build with the type error above, which the SDK change fixes.ai@6depends on@opentelemetry/api@^1.9.0, so the npm tmp install pulls 1.10.0, while the SDK registers its globals from the monorepo's 1.9.1.ai's tracer becomes a no-op, andmainarrives withspans: [].ai@7has no OTel dependency, so only v6 fails. In real installs, both copies dedupe. For the tmp installs, the runner now pins@opentelemetry/apito the SDK's version through an npmoverridesentry.node-otel-without-tracingpins@opentelemetry/api@1.9.0, while@sentry/node's^1.9.1now resolves to 1.10.0. The app registers the context manager through 1.9.0, so Sentry can't read it. Apnpm.overridespin keeps one copy installed.generic-ts3.8already uses the same approach.developis not affected. These apps andwrapSamplingDecisiondon't exist there anymore, so this change is v10-only.This unblocks #25612.
via Junior system actor
event.--
View Junior Session [Sentry]