packages/instrumentation-openai/src/instrumentation.ts (1)

483-497: Tool-call accumulation: assign stable fields (id, type), append only to arguments.

• id should be assigned (not concatenated).
• type should be assigned (already fixed here).
• name may stream in segments, but most servers send it once. To be safe, set on first occurrence, append otherwise.
• arguments should be concatenated, as it streams chunk by chunk.

           if (result.choices[0].message.tool_calls) {
             if (toolCall.id) {
-              result.choices[0].message.tool_calls[toolCall.index].id +=
-                toolCall.id;
+              (result.choices[0].message.tool_calls[toolCall.index] as any).id =
+                toolCall.id;
             }
             if (toolCall.type) {
               result.choices[0].message.tool_calls[toolCall.index].type =
                 toolCall.type;
             }
             if (toolCall.function?.name) {
-              (result.choices[0].message.tool_calls[toolCall.index] as any).function.name += toolCall.function.name;
+              const target = (result.choices[0].message.tool_calls[toolCall.index] as any);
+              if (!target.function.name) {
+                target.function.name = toolCall.function.name;
+              } else {
+                target.function.name += toolCall.function.name;
+              }
             }
             if (toolCall.function?.arguments) {
-              (result.choices[0].message.tool_calls[toolCall.index] as any).function.arguments += toolCall.function.arguments;
+              (result.choices[0].message.tool_calls[toolCall.index] as any).function.arguments +=
+                toolCall.function.arguments;
             }
           }

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-set-attributes-in-span-for-function-calling_1703714575/recording.har (1)

82-85: Add a 5.x “tools” function-calling recording alongside legacy “functions”.

OpenAI 5.x uses tools: [{ type: 'function', function: { ... } }] and often the Responses API. To truly cover 5.x, add a HAR recording that exercises tools (non-streaming and streaming) so instrumentation spans/attributes are validated on the new shape.

Example request body you can capture:

{
  "model": "gpt-4o-mini",
  "messages": [{ "role": "user", "content": "What's the weather like in Boston?" }],
  "tools": [{
    "type": "function",
    "function": {
      "name": "get_current_weather",
      "description": "Get the current weather in a given location",
      "parameters": {
        "type": "object",
        "properties": {
          "location": { "type": "string", "description": "The city and state, e.g. San Francisco, CA" },
          "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
        },
        "required": ["location"]
      }
    }
  }]
}

If you’ve already added such tests elsewhere, ignore this.

packages/instrumentation-openai/test/instrumentation.test.ts (1)

79-81: Ensure OpenAI v5.x Is Exercised in CI

Our inspection shows that every openai dependency is still on v4 and all HAR fixtures record “OpenAI/JS 4.x” in their user-agent. To truly validate v5 support, please address the following:

• Dependencies

• packages/instrumentation-openai/package.json → "openai": "4.38.3"
• packages/traceloop-sdk/package.json → "openai": "4.38.3"
• packages/sample-app/package.json → "openai": "^4.104.0"

• HAR fixtures under
packages/instrumentation-openai/recordings still advertise user-agent v4

Recommendations:

1. Bump openai to ^5.x in your package manifests (or introduce a v4/v5 matrix in CI).
2. Re-record the HAR fixtures using the v5.x client so that user-agent reflects “OpenAI/JS 5.x”.
3. Verify replay still passes under both major versions, if backward compatibility is required.

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-set-attributes-in-span-for-completion_322013537/recording.har (2)

65-67: Prevent header-driven fixture churn (x-stainless-runtime-version).

Same note as other HARs: exclude volatile headers from Polly matching to avoid re-recording when Node/SDK varies.

---

90-96: Sanity-check base64 payload decodes to valid JSON.

Ensure the updated completion payload still decompresses to JSON; see the verification script in the other comment.

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-set-attributes-in-span-for-function-calling_1703714575/recording.har (1)

90-96: Validate function-calling response payload integrity.

Same integrity check as other HARs; the base64 chunks should gunzip to valid JSON.

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-set-attributes-in-span-for-streaming-chat_72904453/recording.har (2)

65-67: Exclude x-stainless- headers from matching.*

Streaming test fixtures also include volatile x-stainless-* headers; exclude them in Polly matchers to avoid re-recording.

---

189-193: Optional: mask set-cookie to reduce churn.

Same rationale as other HARs. If you keep it, prefer masking the value.

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-calculate-correct-tokens-for-different-quality-levels_3292443992/recording.har (2)

90-96: Check JSON integrity for the first image-generation response.

Run the provided verification script to ensure the base64 payload decodes and parses cleanly.

---

281-287: Check JSON integrity for the second image-generation response.

Same as above; verify the multi-kB payload isn’t truncated/corrupted.

packages/instrumentation-openai/src/instrumentation.ts (4)

120-123: Loosening the OpenAI version range is OK; consider adding a soft upper bound.

Changing to ">=3.1.0" enables 5.x, but it may unintentionally pick future major versions with breaking APIs. If you want to be conservative, consider "<6" until you explicitly test 6.x.

-      [">=3.1.0"],
+      [">=3.1.0 <6"],

---

432-437: Avoid broad any; prefer a minimal structural type for the streaming accumulator.

Casting the message to any works but loses type safety. A narrow type keeps compiler help without over-constraining.

-            } as any,
+            } as unknown as {
+              role: "assistant";
+              content: string;
+              tool_calls: Array<{
+                id: string;
+                type: "function" | string;
+                function?: { name: string; arguments: string };
+              }>;
+              // function_call may appear in older tool_call variants
+              function_call?: { name: string; arguments: string };
+            },

---

456-467: Function-call (legacy) streaming likely needs incremental accumulation.

You only set function_call when both name and arguments are present in the same delta. In practice, arguments stream separately. Consider accumulating name/arguments across chunks as you do for tool_calls.

If supporting legacy function_call streaming matters for 5.x, mirror the tool_calls logic: initialize function_call once present, then append arguments across subsequent deltas.

---

702-711: Attribute emission guard is good; additionally check function existence.

To avoid potential undefined access, also ensure toolCall.function is truthy.

-              if (toolCall.type === 'function' && 'function' in toolCall) {
+              if (
+                toolCall.type === 'function' &&
+                'function' in toolCall &&
+                (toolCall as any).function
+              ) {

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-set-attributes-in-span-for-chat_1427850401/recording.har (1)

97-107: Avoid persisting response.cookies unless tests assert on them.

The same cookie appears in both response.cookies and the set-cookie header. If tests don’t assert cookies, drop this block to reduce churn and PII surface.

Apply this diff if cookies aren’t used in assertions:

-          "cookies": [
-            {
-              "domain": ".api.openai.com",
-              "httpOnly": true,
-              "name": "_cfuvid",
-              "path": "/",
-              "sameSite": "None",
-              "secure": true,
-              "value": "ptcvgRCTCq1IFGlU5o6Np6S2Sc3_QtrOzQVs_FAUe.A-1755159619967-0.0.1.1-604800000"
-            }
-          ],
+          "cookies": [],

If you need the presence but not the values, mask them via a beforePersist hook instead.

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-set-attributes-in-span-for-function-calling_1703714575/recording.har (1)

190-193: Mask set-cookie values to reduce fixture churn (optional).

If no test asserts on cookie content, mask the value to a constant to keep diffs minimal between re-recordings.

Apply:

-              "value": "_cfuvid=taZ4ULbzwwbyarAUfW9FCwZOX6yXkJ7aLgBL2DEyid4-1755159626839-0.0.1.1-604800000; path=/; domain=.api.openai.com; HttpOnly; Secure; SameSite=None"
+              "value": "_cfuvid=<masked>; path=/; domain=.api.openai.com; HttpOnly; Secure; SameSite=None"

Alternatively, mask via a Polly beforePersist hook.

packages/instrumentation-openai/recordings/Test-OpenAI-instrumentation_1770406427/should-calculate-correct-tokens-for-different-quality-levels_3292443992/recording.har (1)

158-165: Consider masking or dropping x-content-type-options/set-cookie in image tests.

Token-calculation tests shouldn’t depend on these response headers; masking/dropping them reduces fixture churn and file size.

Proposed minimal diff:

-            {
-              "name": "x-content-type-options",
-              "value": "nosniff"
-            },
-            {
-              "_fromType": "array",
-              "name": "set-cookie",
-              "value": "_cfuvid=duRL0kE4c3tQv8yDth8cAiYfQyZaMw8O8MpX1R4I88A-1755159649952-0.0.1.1-604800000; path=/; domain=.api.openai.com; HttpOnly; Secure; SameSite=None"
-            },
+            // removed volatile headers not used by the test

If any test asserts on these, skip this change.

packages/instrumentation-openai/test/instrumentation.test.ts (2)

417-420: Use strict numeric assertion for token counts.

Normalize the attribute to a number and assert strictly to avoid type drift across SDK versions.

-    assert.equal(
-      completionSpan.attributes[`${SpanAttributes.LLM_USAGE_PROMPT_TOKENS}`],
-      82,
-    );
+    assert.strictEqual(
+      Number(completionSpan.attributes[`${SpanAttributes.LLM_USAGE_PROMPT_TOKENS}`]),
+      82,
+    );

---

517-519: Prefer strict numeric assertion for prompt tokens.

Same rationale as above.

-    assert.equal(
-      completionSpan.attributes[`${SpanAttributes.LLM_USAGE_PROMPT_TOKENS}`],
-      82,
-    );
+    assert.strictEqual(
+      Number(completionSpan.attributes[`${SpanAttributes.LLM_USAGE_PROMPT_TOKENS}`]),
+      82,
+    );

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these settings in your CodeRabbit configuration.

packages/instrumentation-openai/src/instrumentation.ts (2)

367-381: Attribute index collision between functions[] and tools[]

You now emit tools under LLM_REQUEST_FUNCTIONS.* with their own 0-based index, which may overwrite attributes emitted for params.functions.*. Use an offset so tools follow functions, and guard undefined parameters to avoid setting undefined attributes.

Apply this diff:

           params.tools?.forEach((tool, index) => {
             if (tool.type !== 'function' || !('function' in tool) || !tool.function) {
               return;
             }

-            attributes[
-              `${SpanAttributes.LLM_REQUEST_FUNCTIONS}.${index}.name`
-            ] = tool.function.name;
-            attributes[
-              `${SpanAttributes.LLM_REQUEST_FUNCTIONS}.${index}.description`
-            ] = tool.function.description;
-            attributes[
-              `${SpanAttributes.LLM_REQUEST_FUNCTIONS}.${index}.arguments`
-            ] = JSON.stringify(tool.function.parameters);
+            attributes[
+              `${SpanAttributes.LLM_REQUEST_FUNCTIONS}.${(params.functions?.length ?? 0) + index}.name`
+            ] = tool.function.name;
+            attributes[
+              `${SpanAttributes.LLM_REQUEST_FUNCTIONS}.${(params.functions?.length ?? 0) + index}.description`
+            ] = tool.function.description;
+            attributes[
+              `${SpanAttributes.LLM_REQUEST_FUNCTIONS}.${(params.functions?.length ?? 0) + index}.arguments`
+            ] = JSON.stringify(tool.function.parameters ?? {});
           });

---

458-466: Streaming function_call assembly loses partial deltas

Requiring both name and arguments in the same chunk misses the common streaming pattern where they arrive separately. Build the function_call incrementally instead.

Apply this diff:

-        if (
-          chunk.choices[0]?.delta.function_call &&
-          chunk.choices[0]?.delta.function_call.arguments &&
-          chunk.choices[0]?.delta.function_call.name
-        ) {
-          // I needed to re-build the object so that Typescript will understand that `name` and `argument` are not null.
-          result.choices[0].message.function_call = {
-            name: chunk.choices[0].delta.function_call.name,
-            arguments: chunk.choices[0].delta.function_call.arguments,
-          };
-        }
+        if (chunk.choices[0]?.delta.function_call) {
+          // Build up function_call across chunks
+          if (!result.choices[0].message.function_call) {
+            result.choices[0].message.function_call = { name: "", arguments: "" };
+          }
+          if (chunk.choices[0].delta.function_call.name) {
+            result.choices[0].message.function_call.name +=
+              chunk.choices[0].delta.function_call.name;
+          }
+          if (chunk.choices[0].delta.function_call.arguments) {
+            result.choices[0].message.function_call.arguments +=
+              chunk.choices[0].delta.function_call.arguments;
+          }
+        }

packages/instrumentation-openai/src/instrumentation.ts (2)

436-436: Avoid as any for the seeded streaming message (type-safety)

Casting the whole message to any hides mistakes. Consider a narrow local type for the mutable message shape to preserve type-safety.

For example:

type MutableAssistantMessage = {
  role: "assistant";
  content: string;
  tool_calls: Array<{
    id: string;
    type: "function";
    function: { name: string; arguments: string };
  }>;
  function_call?: { name: string; arguments: string };
};

Then initialize:

message: {
  role: "assistant",
  content: "",
  tool_calls: [],
} as MutableAssistantMessage

---

493-497: Tighten typing when mutating tool_calls; optionally avoid as any

The incremental += on function.name and function.arguments is fine for streaming. To reduce reliance on any, introduce a local MutableToolCall type and cast tool_calls once, instead of per-write casts; also ensure the entry has a function object before appending.

Example:

type MutableToolCall = { id: string; type: string; function?: { name: string; arguments: string } };
const calls = result.choices[0].message.tool_calls as unknown as MutableToolCall[];
const entry = calls[toolCall.index];
entry.function ??= { name: "", arguments: "" };
if (toolCall.function?.name) entry.function.name += toolCall.function.name;
if (toolCall.function?.arguments) entry.function.arguments += toolCall.function.arguments;

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these settings in your CodeRabbit configuration.

packages/instrumentation-openai/package.json (1)

58-59: Upgrade instrumentation-openai Node engine requirement to ≥18 and correct the description typo

The OpenAI SDK v5+ requires Node 18+, and your project’s .nvmrc pins Node 20—so bumping the engine floor to 18 is safe. I didn’t find any GitHub Actions workflows (or other CI configs) in .github/workflows; please verify your CI runners (including any .travis.yml or .circleci/config.yml) use Node ≥18.

• packages/instrumentation-openai/package.json
– Update engines.node to ">=18" (was ">=14")
– Fix the “Instrumentaion” → “Instrumentation” typo in description
– (Optional) Change the OpenAI SDK devDependency to ^5.12.2 to pick up non-breaking fixes

 packages/instrumentation-openai/package.json
  4c4
-  "description": "OpenAI Instrumentaion",
+  "description": "OpenAI Instrumentation",
 23,25c23,25
-  "engines": {
-    "node": ">=14"
-  },
+  "engines": {
+    "node": ">=18"
+  },
 58c58
-    "openai": "5.12.2",
+    "openai": "^5.12.2",

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these settings in your CodeRabbit configuration.

packages/instrumentation-openai/src/instrumentation.ts (1)

611-618: Fallback to native Promise when _thenUnwrap is unavailable

Some environments/versions might not expose _thenUnwrap. Add a safe fallback using Promise.then to avoid runtime errors.

   private _wrapPromise<T>(
     type: "chat" | "completion",
     version: "v3" | "v4",
     span: Span,
-    promise: APIPromiseType<T>,
-  ): APIPromiseType<T> {
-    return promise._thenUnwrap((result) => {
+    promise: APIPromiseType<T>,
+  ): APIPromiseType<T> {
+    const unwrap =
+      typeof (promise as any)._thenUnwrap === "function"
+        ? (promise as any)._thenUnwrap.bind(promise)
+        : (onFulfilled: (value: T) => any) =>
+            (Promise.resolve(promise) as Promise<T>).then(onFulfilled);
+    return (unwrap((result: T) => {
       if (version === "v3") {
         if (type === "chat") {
           this._addLogProbsEvent(
             span,
             ((result as any).data as ChatCompletion).choices[0].logprobs,
           );
           this._endSpan({
             type,
             span,
             result: (result as any).data as ChatCompletion,
           });
         } else {
           this._addLogProbsEvent(
             span,
             ((result as any).data as Completion).choices[0].logprobs,
           );
           this._endSpan({
             type,
             span,
             result: (result as any).data as Completion,
           });
         }
       } else {
         if (type === "chat") {
           this._addLogProbsEvent(
             span,
             (result as ChatCompletion).choices[0].logprobs,
           );
           this._endSpan({ type, span, result: result as ChatCompletion });
         } else {
           this._addLogProbsEvent(
             span,
             (result as Completion).choices[0].logprobs,
           );
           this._endSpan({ type, span, result: result as Completion });
         }
       }
 
-      return result;
-    });
+      return result as T;
+    }) as unknown) as APIPromiseType<T>;
   }

packages/instrumentation-openai/src/instrumentation.ts (1)

491-509: Streaming tool_calls assembly: avoid concatenating id and name; only append arguments

It’s incorrect to use += for id and function.name; those should be assigned, not concatenated. Arguments are streamed in chunks and should be concatenated. This also aligns with the prior feedback on "+=" being odd.

-            if (toolCall.id) {
-              result.choices[0].message.tool_calls[toolCall.index].id +=
-                toolCall.id;
-            }
+            if (toolCall.id) {
+              result.choices[0].message.tool_calls[toolCall.index].id =
+                toolCall.id;
+            }
             if (toolCall.type) {
               result.choices[0].message.tool_calls[toolCall.index].type =
                 toolCall.type;
             }
             if (toolCall.function?.name) {
-              (
-                result.choices[0].message.tool_calls[toolCall.index] as any
-              ).function.name += toolCall.function.name;
+              (
+                result.choices[0].message.tool_calls[toolCall.index] as any
+              ).function.name = toolCall.function.name;
             }
             if (toolCall.function?.arguments) {
               (
                 result.choices[0].message.tool_calls[toolCall.index] as any
               ).function.arguments += toolCall.function.arguments;
             }

packages/instrumentation-openai/src/instrumentation.ts (2)

372-389: Guarding tools to only function-type is correct; consider attribute collision with legacy functions

The stricter guard avoids processing non-function tools — good. One consideration: you emit both params.functions and params.tools under the same attribute prefix (llm.request.functions). If both are provided (rare but possible), indices may collide and overwrite attributes.

• Option A: Use a distinct namespace for tools (e.g., llm.request.tools).
• Option B: Offset tool indices by params.functions?.length to avoid collisions.

---

445-445: Avoid broad as any on message if feasible

If you want to avoid the broad cast, introduce a narrow local type for the assistant message that includes optional function_call and tool_calls. This keeps type safety without relying on any.

Example (outside this range):

type AssistantMessage = NonNullable<ChatCompletion["choices"][number]>["message"] & {
  function_call?: { name: string; arguments: string };
  tool_calls?: Array<{
    id: string;
    type: "function";
    function: { name: string; arguments: string };
  }>;
};

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these settings in your CodeRabbit configuration.