You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(deno): Clear pre-existing OTel global before registering TracerProvider #19724
Calls trace.disable() before trace.setGlobalTracerProvider() in @sentry/deno's OTel tracer setup
This fixes silent registration failure when Supabase Edge Runtime (or Deno's native OTel) pre-registers a TracerProvider on the @opentelemetry/api global (Symbol.for('opentelemetry.js.api.1'))
Without this fix, AI SDK OTel spans (gen_ai.*) never reach Sentry because the Sentry TracerProvider is never actually set as the global
Context
Supabase Edge Runtime (Deno 2.1.4+) registers its own TracerProvider before user code runs. The OTel API's setGlobalTracerProvider is a no-op if a provider is already registered, so Sentry's tracer silently gets ignored. Calling trace.disable() clears the global, allowing setGlobalTracerProvider to succeed.
This matches the pattern already used in cleanupOtel() in the test file and is safe because:
It only runs once during Sentry.init()
Any pre-existing provider is immediately replaced by Sentry's
The Cloudflare package was investigated and doesn't have the same issue
Test plan
Updated should override pre-existing OTel provider with Sentry provider test — simulates a pre-existing provider and verifies Sentry overrides it
Updated should override native Deno OpenTelemetry when enabled test — verifies Sentry captures spans even when OTEL_DENO=true
Verified manually with Supabase Edge Functions + AI SDK that gen_ai spans appear in Sentry
Activity
linear-code commentedon Mar 9, 2026
JS-1905
fix(deno): Clear pre-existing OTel global before registering TracerPr…
github-actions commentedon Mar 19, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #19723, which was included in the 10.45.0 release.