fix(deno): Clear pre-existing OTel global before registering TracerProvider

[github-actions]

Note

The pull request "fix(deno): Clear pre-existing OTel global before registering TracerProvider" was created by @sergical but did not reference an issue. Therefore this issue was created for better visibility in external tools like Linear.

Summary

• 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:

1. It only runs once during Sentry.init()
2. Any pre-existing provider is immediately replaced by Sentry's
3. 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

🤖 Generated with Claude Code

[linear-code]

JS-1905