fix(openai): fix tracing exception in model response getting method when tracing is disabled

[upphiminn]

This pull request addresses a possible issue in the OpenAIResponsesModel where an exception could occur during getting a response when tracing is disabled. When tracing is disabled there is no parent trace so withResponseSpan fails with not finding a context trace for the span it attempts to create. This leads to the whole getResponse failing. Fix found below copies the same style of span creation only when tracing is enabled as seen in getStreamedResponse method.

[seratch]

This looks good to me; @dkundel-openai any concern?

[dkundel-openai]

This seems odd because if tracing is disabled there should still be a NoopTrace that this should get attached to?

[dkundel-openai]

The main thing is that not using withResponseSpan() means that we are not creating a new entry in the Async Context Store which could create race condition issues so we should avoid it wherever possible

[seratch]

@dkundel-openai thanks for the good point.
@upphiminn can you share what actually happens in this scenario? > When tracing is disabled there is no parent trace so withResponseSpan fails with not finding a context trace for the span it attempts to create.

If we figure the root cause out, the fix can be much simpler than rewriting a bunch of code.

[seratch]

to avoid confusion, let me revert the approval for now

[upphiminn]

Hello 👋🏻 @seratch @dkundel-openai, thank you for the reply. The issue can be verified by running the unit test that was added on the original code. When the tracing is set to disabled the code throws a 'No existing trace found' exception. I don't know the internal details of the tracing code, but it seems that even in the tests (for example the one at line 15 in the unit test file modified) there is an assumption that a trace exists. In practice, while looking into it, I didn't find the code path will create a Noop trace by the time it gets there.

The overall usage context was using the (Azure OpenAI Service) Github Models API, which doesn't seem to work with the Agents JS SDK as far as I tried, but does work with the Agents Python one. Due to this API not supporting tracing it must be disabled but that seems to fail somehow (although I tried in many ways to disable tracing, via env var flag, via RunConfig, via globalTraceProvider directly or via ModelRequest tracing property, none seem to had the desired effect, and this seemed like one of the causes of failure – I also might have tried too hard to disable it 😄)

[upphiminn]

@seratch @dkundel-openai Here is also a sample stack trace when attempting to call the API:

{"message":"No existing trace found","name":"Error","stack":"Error: No existing trace found\n    at withNewSpanContext (/Users/xxx-redacted-xxx/node_modules/@openai/agents-openai/node_modules/@openai/agents-core/dist/tracing/context.js:141:15)\n    at <anonymous> (/Users/xxx-redacted-xxx/node_modules/@openai/agents-openai/node_modules/@openai/agents-core/dist/tracing/createSpans.js:6:16)\n    at OpenAIResponsesModel.getResponse (/Users/xxx-redacted-xxx/node_modules/@openai/agents-openai/dist/openaiResponsesModel.js:725:32)\n    at <anonymous> (/Users/xxx-redacted-xxx/node_modules/@openai/agents/node_modules/@openai/agents-core/dist/run.js:151:63)" }

Overall the code looks like this:

  // config
  const customClient = new OpenAI({ baseURL: _config.github.modelEndpoint, apiKey: _config.github.token })
  setTracingDisabled(true)
  setDefaultOpenAIClient(customClient)

   // usage
   const agent = new Agent({
    name: 'Assistant',
    instructions: 'You are a helpful assistant',
  })
  const result = await run(agent, 'Write a haiku about recursion in programming.', {})

The version used are:

  "@openai/agents": "0.0.14",
  "openai": "5.10.2"

[github-actions]

This PR is stale because it has been open for 10 days with no activity.

[Nirator78]

Any news for this bug ?

[seratch]

Something inside the tracing logic that creates noop one, but we haven't figured what the viable solution is out yet.

[upphiminn]

@seratch On my side I also didn't have time to look into it more either, I can't say I fully understand the argument regarding the withResponseSpan wrapper function yet. The getStreamedResponse below this method is using the exact same technique as in this PR, so from my understanding I don't see why it would be an inappropriate fix (does this mean the other method might also have some unknown defect not surfacing just because it's not using withResponseSpan?);

[seratch]

@upphiminn Thanks for taking the time to check this issue. I've managed to see the situation with 0.0.16 but it no longer occurs with 0.0.17, which was just released with a fix for CJS/ESModule build issue. Perhaps, the library source resolution might be the cause. Let me close this one, but please feel free to write in and/or create a new issue if necessary.