Conversation
| openaiClient.responses.create = ((...args: Parameters<typeof responsesCreate>) => { | ||
| const [body, options = {}] = args; | ||
| const nextBody = { ...body, ...(options.body || {}) }; | ||
| const nextBody = { ...body, ...((options.body as Record<string, unknown>) || {}) }; |
There was a problem hiding this comment.
Seems do not need this change.
There was a problem hiding this comment.
The cast is needed because options is inferred as unknown from the overloaded function signature. Without it, the browser build fails with TS2698: Spread types may only be created from object types.
| return openaiClient; | ||
| } | ||
|
|
||
| function setCommonSpanAttributes( |
There was a problem hiding this comment.
Let's move these util function to other files.
| export async function _createDeserialize(result: PathUncheckedResponse): Promise<Agent> { | ||
| const expectedStatuses = ["200"]; | ||
| if (!expectedStatuses.includes(result.status)) { | ||
| console.error("[DEBUG] agents.create failed with status:", result.status, "body:", JSON.stringify(result.body)); |
| * Enable GenAI tracing for Azure AI Projects agent operations | ||
| * and response generation. | ||
| */ | ||
| export function enableGenAITracing(): void { |
There was a problem hiding this comment.
This system of enabling/disabling genAI tracing should not be needed or used. Our core-tracing implementation already no-ops by default and is safe to call. The end-user will enable OTel based tracing by configuring https://www.npmjs.com/package/@azure/opentelemetry-instrumentation-azure-sdk prior to loading @azure/ai-projects
By adding another flag we are duplicating what is already configurable at the Azure SDK level and adding another concept for users to learn and understand. There are also nuances to setting an in-memory value (side-by-side versioning, CJS/ESM compatibility, etc).
So the TL;DR is:
- Use
coreTracing.createTracingClientto create a properly configured tracing client (no-op by default, enabled if the user enables OTel tracing) - Wrap calls to be traced with tracingClient.withSpan
- Access the inner span as needed to add custom attributes inside the callback, you are already doing this
- Remove everything in this file and any conditionals based on these checks
- You can wrap calls with tracingClient.withSpan, they are not expensive or harmful, and do nothing unless the user configured OTel instrumentation
As far as the environment variables, we do not use custom environment variables or introduce new environment variables unless absolutely necessary. We should have a discussion about what your needs are here and how we can best configure them.
Feel free to ping me with any questions!
| */ | ||
| export function isContentRecordingEnabled(): boolean { | ||
| try { | ||
| return process.env.OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT === "true"; |
There was a problem hiding this comment.
Are tracing spans the right place for message content? Ideally we'd want to be careful with user provided content. We can use the Azure Logger at verbose level or I would think we can omit it entirely. The user can still create their own spans and capture the agent output as needed before/after calling into our SDK but maybe I missed a non-presumptive feature ask here
4 participants
adding agent tracing