AI SDK calls fail with `ReadableStream has already been used` when OTEL enabled

[parteeksingh24]

AI SDK calls in SSE handlers fail with ReadableStream error when OTEL is enabled, despite the #471 fix.

Issue

Error: ReadableStream has already been used
Error: Connection lost

Observed in Model Arena demo within the SDK explorer where Anthropic provider shows the error and connection drops.

Workaround:

OTEL_SDK_DISABLED=true bun run dev

Potential Cause

The #471 fix wraps SSE handlers in ROOT_CONTEXT to bypass OTEL-instrumented fetch. This works for simpler cases but still fails when:

• Using generateObject (not just generateText)
• Running multiple AI SDK calls in parallel within an SSE handler

Potential Fixes

1. Check if generateObject triggers different OTEL instrumentation paths than generateText
2. Investigate whether parallel AI SDK calls inside SSE handlers need additional handling
3. Verify ROOT_CONTEXT propagates correctly through Promise.all() with multiple provider calls

[linear]

AGENT-1325

[parteeksingh24]

Ran into this with another example (SSE handler + generateText with tools + sandbox.execute()). The error fires on first request, every time, unless OTEL_SDK_DISABLED=true is set.

The #537 fix wraps SSE handler execution in ROOT_CONTEXT so the SDK's instrumented fetch falls through to __originalFetch when there's no active span. This addresses the SSE handler's direct fetch calls, but misses paths that re-introduce active spans inside the same handler.

1. Sandbox service withSpan() re-introduces active spans

services/sandbox/http.js wraps every sandbox operation in withSpan():

async function withSpan(name, attributes, fn) {
    const currentContext = context.active(); // ROOT_CONTEXT here
    const span = tracer.startSpan(name, { attributes, kind: SpanKind.CLIENT }, currentContext);
    const spanContext = trace.setSpan(currentContext, span);
    const result = await context.with(spanContext, fn); // fn now has an active span
}

Even from ROOT_CONTEXT, this creates a new root span and runs the inner function with that span active. Any fetch inside sandboxExecute (via APIClient) now runs with an active span, re-enabling the instrumented fetch path.

2. getNodeAutoInstrumentations() adds a second instrumentation layer

otel.js registers the full Node auto-instrumentation suite:

instrumentationSDK = new NodeSDK({
    instrumentations: [getNodeAutoInstrumentations()],
});

This includes @opentelemetry/instrumentation-http, which patches Node's HTTP module. In Bun, this may also intercept fetch calls at a layer below the SDK's own globalThis.fetch wrapper — ROOT_CONTEXT doesn't prevent it from running.

3. __originalFetch may already be Bun's patched fetch

The SDK saves the original fetch at module load time (export const __originalFetch = fetch). If Bun's built-in OTEL has already patched fetch before this module loads, __originalFetch is Bun's instrumented version. The ROOT_CONTEXT bypass just falls through to another instrumented fetch.

The trigger

The upstream cause is oven-sh/bun#24766 (still open): Bun's OTEL-instrumented fetch conflicts with ReadableStream.tee(), which the AI SDK uses internally. When any of the paths above re-introduce OTEL instrumentation around a fetch whose response body gets tee'd, the stream is consumed before the AI SDK can read it.

Potential fixes

1. Have withSpan() respect ROOT_CONTEXT — check trace.getActiveSpan() before creating a span. If null (caller opted out of tracing), skip span creation and call fn directly.

2. Scope getNodeAutoInstrumentations() — exclude @opentelemetry/instrumentation-http since the SDK already has its own fetch wrapper. Removes the second instrumentation layer.

3. Use __originalFetch for internal SDK API calls — sandbox, KV, vector, and stream services could use the saved original fetch directly, bypassing all instrumentation for internal infrastructure calls.

4. Save fetch before Bun patches it — if Bun's OTEL patches fetch at startup, the current save is too late. A preload script or earlier module initialization could capture the truly unpatched fetch.

Environment: SDK 1.0.33, Bun 1.3.10

[parteeksingh24]

Still reproducing on the deployed SDK Explorer (within apps/docs).

Repro:

• https://agentuity.dev/explorer/model-arena
• backing route: /api/model-arena/stream

Observed SSE output:

• both provider generations fail with ReadableStream has already been used
• the judge then fails with Judge failed: ReadableStream has already been used

This still looks different from the original #471 path:

• ROOT_CONTEXT appears to fix the direct “AI SDK call inside sse() handler” case
• tracing seems to get turned back on later inside the same request

Likely path:

1. sse() enters ROOT_CONTEXT
2. our build/dev patch paths still force experimental_telemetry: { isEnabled: true }
   • packages/cli/src/cmd/build/patch/aisdk.ts
   • packages/runtime/src/dev-patches/aisdk.ts
3. AI SDK telemetry itself uses tracer.startActiveSpan(...)
   • node_modules/ai/src/telemetry/record-span.ts
4. once an active span exists again, packages/runtime/src/otel/fetch.ts stops using the plain fetch path
5. that still lines up with Bun’s upstream stream-lock bug:
   • oven-sh/bun#24766

So the main suspects at this point seem to be:

• packages/runtime/src/otel/otel.ts still registers full getNodeAutoInstrumentations(), including @opentelemetry/instrumentation-http
• our build/dev patch paths still force experimental_telemetry: { isEnabled: true }, and AI SDK telemetry itself uses tracer.startActiveSpan(...)
• that looks like a cleaner explanation for tracing getting turned back on after ROOT_CONTEXT

One gap in the current coverage:

• packages/runtime/test/sse-async-fetch.test.ts still passes
• but it only covers the older #471 shape
• it does not cover:
  • forced experimental_telemetry
  • parallel generateText()
  • then generateObject()
  • inside one SSE handler

The most likely SDK-side fixes still seem to be:

• on Bun, disable or narrow outgoing HTTP auto-instrumentation, especially @opentelemetry/instrumentation-http
• avoid re-enabling spans inside SSE handlers that already opted out via ROOT_CONTEXT
• add an integration test for sse() + parallel generateText() + generateObject() with OTEL enabled