Node tracing silently disabled when the OTel API global pre-exists with a different @opentelemetry/api version

[sergical]

Description

When the OTel API global (Symbol.for('opentelemetry.js.api.1')) already exists with a version that differs from the SDK's @opentelemetry/api copy — even by a patch release — registerGlobal's exact-version check rejects trace.setGlobalTracerProvider(). setupSentryTracerProvider returns [undefined, undefined] with only a debug-build warning, and every span — including Sentry.startSpan() — is silently non-recording. Errors and logs keep working, so nothing looks broken until you notice traces are missing.

trace.disable() before init does not help: the rejection comes from the version gate, not an occupied trace slot.

This is the Node flavor of the Deno/Supabase issue fixed in #19723. Hit in production on Neon Functions, whose runtime pre-creates the global with api 1.9.0 while @sentry/node@10.66.0 resolves 1.9.1.

Reproduction

// simulates a host runtime that created the global with a different api version
globalThis[Symbol.for('opentelemetry.js.api.1')] = { version: '1.9.0' };

const Sentry = await import('@sentry/node'); // resolves @opentelemetry/api 1.9.1
Sentry.init({ dsn: '<dsn>', tracesSampleRate: 1 });

Sentry.startSpan({ name: 'test' }, (span) => span.isRecording()); // false
// Sentry.getClient().traceProvider === undefined

Expected

Either the SDK claims the global (delete/recreate, as #19723 does for Deno, gated on skipOpenTelemetrySetup), or the failure is loud outside debug builds — today it is invisible.

Userland workaround: delete globalThis[Symbol.for('opentelemetry.js.api.1')] before Sentry.init().

[linear-code]

JS-3070