tracing/`defaultProcessor()` breaks Cloudflare Workers runtime

[threepointone]

Describe the bug

Cloudflare Workers has a constraint where you can't start async i/o outside of the context of a request (so you can't do a setTimeout/fetch etc until a request comes in). We do this for performance and security reasons.

OpenAI agents starts collecting traces over here

openai-agents-js/packages/agents-core/src/index.ts

Line 150 in b9a6554

addTraceProcessor(defaultProcessor());

as soon as the module is loaded. This makes Workers throw an error, which looks like this:

Uncaught Error: Disallowed operation called within global scope. Asynchronous I/O (ex: fetch() or
  connect()), setting a timeout, and generating random values are not allowed within global scope.
  To fix this error, perform this operation within a handler.
  https://developers.cloudflare.com/workers/runtime-apis/handlers/
    at null.<anonymous> (server.js:21280:29) in <instance_members_initializer>
    at null.<anonymous> (server.js:21281:14) in BatchTraceProcessor
    at null.<anonymous> (server.js:21428:25) in defaultProcessor
    at null.<anonymous> (server.js:28636:19)
   [code: 10021]

(Annoyingly, while this error does show in wrangler dev and in production, it doesn't show with the vite plugin, which is why I missed this until it was reported to me)

So a fix could be that we don't start the batch processor if navigator.userAgent === 'Cloudflare-Workers, and it's up to the developer to add trace collection manually.

Filing this issue to discuss before I start thinking of solutions / sending PRs.

Debug information

• Agents SDK version: v0.0.2
• Runtime environment workerd@1.20250604.0

Repro steps

https://github.com/RogutKuba/test-openai-sdk pnpm install && pnpm start

Expected behavior

It, um, shouldn't crash.

[dkundel-openai]

That makes sense. Since this is a cloudflare workers specific issue, I wonder if adding a flag that is turned off in the shims-workerd.ts and potentially in browser as well makes more sense. That way we are not adding a userAgent flag runtime check into the processor part. We already turn it off in the browser here https://github.com/openai/openai-agents-js/blob/main/packages/agents-core/src/tracing/processor.ts#L128 using that same approach.

The only thing with this is that it might run into the same bug as #10

[Manouchehri]

I really do want automatic trace collecting in Workers with this SDK though. :(

Couldn't we use .waitUntil in the tracer here?

[dkundel-openai]

The other option we could have is have two entry points of the SDK. The default one that has tracing enabled by default and needs to use a dynamic import (see our integration tests) and one that doesn't where you need to enable it yourself. Though enabling shouldn't be hard either way

[whoiskatrin]

Couldn't we use .waitUntil in the tracer here?

i think since the tracer runs outside of any request context, there’s no event instance to call waitUntil on really

[dkundel-openai]

Took a stab at fixing this in #50 but it does require to call startTracingExportLoop (example in #50)

[bndkt]

@threepointone @dkundel-openai have you verified this in a Durable Object already? When using this in a Worker it runs fine for me, but in a Durable Object I get the following error:

[vite] Internal server error: Cannot read properties of undefined (reading 'fd') at async ProxyServer.fetch (file:///.../node_modules/miniflare/src/workers/core/proxy.worker.ts:173:11)

[threepointone]

Yeah I'm seeing this issue, it has to do with the wrong build of debug being picked up, I'll figure out a fix today

[bndkt]

Man you're fast 🚀

[threepointone]

in the meanwhile, you can apply this patch while I figure it out https://github.com/threepointone/openai-cloudflare-agents/blob/main/patches/debug%2B4.4.1.patch

[threepointone]

ok, I figured this out, this is a bug with our vite plugin cloudflare/workers-sdk#9562 I'll chase them down to fix it