Validate feasibility of supporting new attribute types

[pellared]

What

Investigate whether it is possible and acceptable to extend the OTel JS API and SDK with new attribute types.

Guidelines for evolving API/SDK: https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#how

Prototype in OTel Go demonstrating feasibility of adding new attribute types: open-telemetry/opentelemetry-go#6809

Why

Per open-telemetry/opentelemetry-specification#4602

Follows open-telemetry/opentelemetry-specification#4614

The goal is to make sure that PRs like these are acceptable for OTel JS:

• all: drop attribute values restrictions opentelemetry-proto#707
• [EndGoal] [DoNotMerge] Extend the set of attribute value types opentelemetry-specification#4636

[pellared]

During the SIG meeting @dyladan noted that there are some other API implementations that may be impacted. We should reach to them so that they at least aware.

[pellared]

@open-telemetry/javascript-maintainers, ping

You can also review open-telemetry/opentelemetry-specification#4651

[pichlermarc]

I think it is not possible to extend the Attributes type in way that's non-breaking for both the API and SDK, but there are ways around it.

The way it's implemented right now, end-users use this type directly in their code: they "implement" Attributes and pass it to the API. As such they may also use that type for any utility functions they may have for instrumenting their code. If we were to change this type I would expect a massive amount of end-users being broken as a result - suddenly the type definitions may be wider than they expect in all places where they accept Attributes and that will lead to compile-time errors in certain cases.

I think the best we could do is this:

• introduce a new type ComplexAttributes that follows the proposed spec
• raise the minimum supported API versions in all SDKs that are supposed to use this new type in their public API

So for stable SDKs (traces, metrics), the earliest that we could implement this would be SDK 3.0 (currently planned around June 2026) for stable SDKs. For in-development SDKs like Logs we can do it right now since we're still able to introduce breaking changes.

So yes, we can do it - there's just no simple or elegant way.

[pichlermarc]

The approach with ComplexAttributes is what we had planned to do with the Logs API/SDK. Today they export a LogAttributes type that allows for complex attributes to be defined and that was supposed to co-exist with Attributes.

[pellared]

currently planned around June 2026

Not bad IMO 😉

@pichlermarc, can we close this issue or do you plan to do more discussions and research?

[pichlermarc]

I'll have some more discussions to get a few opinions and will report here on the outcome next week.