fix (ai/core): Add null check for OTEL attributes

[kdawgwilk]

My mind was boggle today when i learned that in JS (typeof null === 'object') === true So this helps protect from trying to access 'input' in null which throws below

[lgrammel]

Can you provide a reproduction code example for the bug that this fixes?

[kdawgwilk]

It's not necessarily a bug because OTEL doesn't like undefined or null attributes but some the attributes we were passing to our tracing lib langsmith ended up being null and caused a crash. I figured since this was already handling undefined values adding null check wouldn't be too big of an issue. I can try and pull together a MRE. I thought a failing test would be enough to cover it.

[kdawgwilk]

What are the major concerns with adding a more defensive check here? Is it the new null type on the argument that no longer enforces values to not be null by TS that you are concerned about?

[lgrammel]

We need to support OTEL not LangSmith. Passing null is valid according and supported by the OTEL schema / standard (pls correct if wrong), and there are legit use cases (you may want to pass null for some custom values some times). If LangSmith crashes, but it's bc they don't handle things correctly, it needs to be fixed on their end.

[kdawgwilk]

Alright here is the MRE without a dependency on langsmith

import { generateText } from 'ai';
import { ollama } from 'ollama-ai-provider';

const model = ollama('llama3.2');

const prompt = 'Tell a joke';
const result = await generateText({
  model,
  prompt,
  experimental_telemetry: {
    isEnabled: true,
    metadata: {
      // @ts-expect-error
      nullValue: null,
      prompt,
    }
  },
});
  
console.log(result.text);

Error:

/Users/username/Sources/pocs/ai-otel-bug-repro/node_modules/ai/core/telemetry/select-telemetry-attributes.ts:30
      'input' in value &&
      ^

TypeError: Cannot use 'in' operator to search for 'input' in null
    at <anonymous> (/Users/username/Sources/pocs/ai-otel-bug-repro/node_modules/ai/core/telemetry/select-telemetry-attributes.ts:30:7)
    at Array.reduce (<anonymous>)
    at selectTelemetryAttributes (/Users/username/Sources/pocs/ai-otel-bug-repro/node_modules/ai/core/telemetry/select-telemetry-attributes.ts:22:37)
    at generateText (/Users/username/Sources/pocs/ai-otel-bug-repro/node_modules/ai/core/generate-text/generate-text.ts:247:17)
    at <anonymous> (/Users/username/Sources/pocs/ai-otel-bug-repro/index.ts:7:22)
    at ModuleJob.run (node:internal/modules/esm/module_job:234:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:473:24)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:122:5)

Node.js v20.18.1

[lgrammel]

I'm getting the following (expected) typescript error:

AttributeValue comes from OTEL and does not support null:

export declare type AttributeValue = string | number | boolean | Array<null | undefined | string> | Array<null | undefined | number> | Array<null | undefined | boolean>;

https://github.com/open-telemetry/opentelemetry-js/blob/main/api/src/common/Attributes.ts#L35

I'm trying to understand the request here. Do you want us to support null (which is not supported by OTEL)?

[kdawgwilk]

I really appreciate the thought and effort that has gone into maintaining this library—thank you for your time and for engaging in this discussion.

The current approach works well for strictly typed TypeScript codebases, but in practice, many real-world projects either don’t use TypeScript or don’t enforce strict types across their entire codebase. Because of that, it would be ideal if passing null as a metadata property didn’t result in an error. Right now, the library already allows undefined values, even though the OTEL AttributeValue documentation suggests they shouldn’t be permitted:

From what I see, there are three potential paths forward:

1️⃣ Leave it as-is, requiring consumers of the library to manually filter out null values before passing attributes, which could lead to unexpected crashes if they don’t.
2️⃣ Merge this PR and handle null values safely rather than throwing an error, similar to how undefined values are already treated. We could also log a warning to inform users that null attributes are being ignored if that is desired.
3️⃣ Remove undefined from the attributes type to better align with OTEL requirements, though this would be a breaking change.

I personally think option 2 is the most pragmatic approach since it prevents unexpected crashes while maintaining flexibility for different use cases. I’d love to see this merged, as it directly solves an issue I ran into.

That said, I completely understand that I’m just an external contributor and that maintainers have a broader perspective on the project. If you feel another approach is better, I respect that decision and appreciate you taking the time to consider this!

Thanks again for your work on this project! 🚀