hi @aperezfals, thanks for the contribution & resolution to the issue you identified! i left one comment related to testing this.

but additionally, another thought - i think you should not need to rely on both our integration and the underlying OTel interface/integration when using the Datadog OTel trace provider, but rather one or the other. so, from your issue, using either

import tracer from 'dd-trace'
tracer.init(...)

import { generateText } from 'ai'

await generateText({ ... }) // leave out experimental telemetry and tracer as the DD instrumentation will handle it properly

or

export DD_TRACE_DISABLED_INSTRUMENTATIONS=ai

import tracer from 'dd-trace'
tracer.init(...)
new tracer.TracerProvider().register()

import { generateText } from 'ai'

await generateText({ ...,  experimental_telemetry: { isEnabled: true, tracer: trace.getTracer('ai') } }) // leave out experimental telemetry and tracer as the DD instrumentation will handle it properly

but not both. let me know if migrating to one of these scenarios (either relying on the DD instrumentation but not OTel trace provider, or not relying on the DD instrumentation but on the OTel trace provider) helps in your case without this fix.

Hi @sabrenner, thanks for looking at this and for the thoughtful suggestion! I want to clarify why I think the fix is still needed even setting aside the "dual path" scenario.

The bug actually reproduces with a single path through dd-trace — no explicit experimental_telemetry.tracer required. The setup is:

const tracer = require('dd-trace').init({ ... })
tracer.use('ai', { enabled: true })      // DD ai instrumentation active
new tracer.TracerProvider().register()    // DD registered as global OTel provider

await generateText({ model, messages })  // no experimental_telemetry at all

Here's the sequence that leads to the crash:

1. selectTelemetryAttributesChannel (in packages/datadog-instrumentations/src/ai.js) forces telemetry.isEnabled: true on the ai SDK options, so telemetry is enabled even when the user didn't configure it.
2. The ai SDK calls its internal getTracer(), which (with no explicit tracer: passed) fetches the global OTel tracer via trace.getTracer('ai').
3. Since DD is the global OTel provider, that returns a DD bridge tracer.
4. getTracerChannel fires and wrapTracer(bridgeTracer) is called.
5. When the ai SDK calls startActiveSpan, it gets a BridgeSpanBase instance.
6. Object.create(bridgeSpan) creates a prototype clone that fails the private-field brand check.
7. Any ai SDK error path calls span.setStatus({ code: SpanStatusCode.ERROR }) on the clone → TypeError: Cannot read private member #statusCode.

So the issue is not about using two overlapping export paths — it's about two dd-trace subsystems (the ai instrumentation and the OTel bridge) being incompatible with each other when used together. The ai instrumentation forces OTel telemetry on even when the user doesn't configure it explicitly, and if DD is the global OTel provider, that's enough to hit the crash.

Your Option A avoids the crash because it skips registering the OTel provider (so trace.getTracer() returns a noop tracer with no private fields). Your Option B avoids it because it disables the ai instrumentation entirely (so wrapTracer is never called). But both workarounds require giving up a legitimate feature: either OTel bridge compatibility or DD ai instrumentation. The intended configuration — DD as the global OTel provider for ecosystem compatibility, with DD ai instrumentation active for AI-specific span enrichment — is reasonable and should work.

The Object.create(span) pattern is also fundamentally unsafe as a generic span wrapper regardless of this specific scenario: it breaks for any span implementation that uses private fields, not just BridgeSpanBase. The delegating wrapper fixes the root incompatibility for all current and future span implementations.

🔄 Datadog auto-retried 1 job - 1 passed on retry

@sabrenner can you run CI again?

Hey @aperezfals, I've gone ahead and re-run the CI + merged since everything looks good :)
This fix will be included in an upcoming release of dd-trace-js, you can keep an eye on the release notes to confirm it's included.

Thanks again for the contribution!