DurableAgent never emits its streamText span even though experimental_telemetry reaches it (sibling generateObject steps emit fine)

[shtefcs]

We run DurableAgent on the managed Vercel world and our agent spans never show up in our OTel backend (Langfuse span processor registered through @vercel/otel). Steps in the same workflow that call generateObject directly emit fine. Two days of production traffic: hundreds of routing spans, zero agent spans.

Versions: workflow 5.0.0-beta.24, @workflow/ai 5.0.0-beta.11, ai 6.0.141, next 16.2.9, @vercel/otel v2, Node 20 on Vercel.

What we ruled out before filing:

• The config reaches the SDK. We logged it in the workflow body at the .stream() call site and got the full object: {"isEnabled":true,"functionId":"agent.general.main","metadata":{...}}.
• Instrumentation is registered. Our register() log line appears in the same invocation's logs as the run.
• Ingestion is healthy. routing.classify spans from the very same run (a generateObject inside a "use step") arrive a couple minutes later. The agent's own span from that run never does.
• Not our local patch. We carry a small patch on @workflow/ai for step latency attributes, but it doesn't touch agent/telemetry.js or recordSpan, and the loss reproduces with the config confirmed intact at the boundary.

Where it seems to sit, from reading the dist: doStreamStep wraps model.doStream with recordSpan('ai.streamText.doStream') from agent/telemetry.js. So either options.experimental_telemetry doesn't survive the step argument serialization into doStreamStep (that options bag also carries transforms, which are functions), or getTracer / startActiveSpan silently no-ops inside the step invocation. The outer 'ai.streamText' span from streamTextIterator probably can't exist at all, since the iterator runs in the workflow body where import("@opentelemetry/api") fails and recordSpan takes the no-op path by design.

Is experimental_telemetry expected to work end to end through DurableAgent on the managed world? If yes, a pointer on where to instrument next would help. Happy to test a nightly build or add debug output on our side, we can reproduce this on demand.

Repro sketch: any DurableAgent with experimental_telemetry set and a span processor registered via @vercel/otel, compare span arrivals against a plain generateObject inside a "use step" in the same workflow.

[shtefcs]

Update from our side, and an apology for the noise. This turned out to be our bug, not the SDK's.

Two separate things were stacked, which is why the picture kept shifting while I was reporting it.

First, the part that explains the original symptom. @workflow/ai resolves the OTel API with Function('return import("@opentelemetry/api")'). That hides the import from bundlers on purpose, but it also hides it from @vercel/nft, so the package was never traced into our serverless bundle. At runtime the import threw, ensureOtelApi caught it and set otelApi to null, getTracer then returned null, and recordSpan took the no-op path. No span, no error, nothing in the logs. Sibling generateObject steps were unaffected because the ai package resolves OTel normally, which is exactly the asymmetry I described.

We fixed it on our side by handing the already registered @opentelemetry/api instance to the module through globalThis and reading that first, keeping the original dynamic import as a fallback. agent.general.main:ai.streamText.doStream now arrives on every durable run. Verified on wrun_01M0GTPR0VP60T1RE9VKYAW0EA.

Second, and this one was entirely self inflicted. We had added the Sentry Node SDK, whose init() calls trace.setGlobalTracerProvider. Our Next.js instrumentation loaded Sentry before our own OTel setup, so Sentry won the global slot, and @opentelemetry/api then refused our registration outright (registerGlobal returns false on duplicate registration, reported only through a diag logger that is silent by default). With tracesSampleRate at 0, every span in the process was non recording. That took our routing spans away too, after this issue was filed, and it made everything unmeasurable for a while. skipOpenTelemetrySetup: true on the Sentry side fixed it.

So the answer to my own question is yes, experimental_telemetry does work end to end through DurableAgent on the managed world. Sorry for the false alarm, and thanks for building this.

Two small suggestions, only if they seem worth it:

1. The catch in ensureOtelApi is silent. One console.warn there would have saved us several days, because the failure mode is total (every span in that module vanishes) and there is no other signal anywhere.

2. Since the import is deliberately invisible to bundlers, a line in the docs saying @opentelemetry/api has to be a real dependency of the app and reachable from the deployed bundle would help. Alternatively, an option to pass in a tracer or the OTel API directly would remove the resolution question entirely.

Closing this since it is resolved for us. Happy to open a separate issue for either suggestion if you would find that useful.