Complex attributes incubating implementation #7814

trask · 2025-11-05T03:43:00Z

Based on prototype option C (#7813)

codecov · 2025-11-06T00:25:31Z

Codecov Report

❌ Patch coverage is 80.11364% with 35 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.17%. Comparing base (a83275a) to head (b91d3bb).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
...a/io/opentelemetry/sdk/internal/AttributeUtil.java	63.04%	14 Missing and 3 partials ⚠️
...r/common/ArrayBackedExtendedAttributesBuilder.java	84.61%	6 Missing and 4 partials ⚠️
...ncubator/common/ArrayBackedExtendedAttributes.java	86.20%	3 Missing and 5 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7814      +/-   ##
============================================
+ Coverage     90.16%   90.17%   +0.01%     
- Complexity     7229     7321      +92     
============================================
  Files           821      822       +1     
  Lines         21809    22007     +198     
  Branches       2136     2180      +44     
============================================
+ Hits          19664    19845     +181     
- Misses         1476     1488      +12     
- Partials        669      674       +5

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

api/all/src/main/java/io/opentelemetry/api/common/ArrayBackedAttributesBuilder.java

jkwatson

Anyone who wants to use the Value type should be scared off by looking at the complexity of the implementation. 😂 Thanks!

jack-berg · 2025-11-17T23:08:56Z

I was kinda hoping we could merge this right into the stable Attributes to reduce churn. After all, ExtendedAttributes served its job and helped provide feedback to the spec. What feedback might we get from iterating again on ExtendedAttributes? Should we weigh the probability of feedback against the cost / inconvenience of churn?

trask · 2025-11-18T00:00:26Z

we can't merge it into stable until Jan 15 (6 months after the OTEP was merged)

trask · 2025-11-18T18:15:51Z

TODO: implement attribute limits

jack-berg · 2025-11-18T21:16:28Z

TODO: implement attribute limits

Is there consensus on how to do this?

trask · 2025-11-18T21:45:55Z

Is there consensus on how to do this?

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#attribute-limits

jack-berg · 2025-11-18T21:17:43Z

...bator/src/main/java/io/opentelemetry/api/incubator/common/ArrayBackedExtendedAttributes.java

+        return asValue(currentKey.getType(), value);
+      }
+    }
+    return null;


Would this implementation benefit from #7076?

jack-berg · 2025-11-18T22:27:41Z

...rc/main/java/io/opentelemetry/api/incubator/common/ArrayBackedExtendedAttributesBuilder.java

+    switch (valueObj.getType()) {
+      case STRING:
+        data.add(stringKey(keyName));
+        data.add(valueObj.getValue());


Can use a pattern like: put(stringKey(keyName), ((Value<String>) valueObj).getValue()) to save a few lines.

Is there a way to be able to store the value key without having to convert it to a string / long / double / etc key first? I.e. something like:

Always store the value key

When fetching for a given key, say of type string, check:

If there is a matching key with type string

OR if there is a matching key of type value and with a value of type string

Can use a pattern like: put(stringKey(keyName), ((Value<String>) valueObj).getValue()) to save a few lines.

575535d

Is there a way to be able to store the value key without having to convert it to a string / long / double / etc key first? I.e. something like:

Always store the value key

When fetching for a given key, say of type string, check:

If there is a matching key with type string

OR if there is a matching key of type value and with a value of type string

I think it's easier to store them in the format we want to expose them via asMap() and forEach()

Ok, but there's obviously a steep perf penalty for making a copy of the attribute key every time. Maybe that's fine as it provides a disincentive for using VALUE where not necessary. Could also solve with an optimization in ExtendedAttributeKey, where we precompute and/or cache the primitive attribute key equivalent when the type is VALUE. Then, this code could leverage the preocmputed / cached value.

Ok, but there's obviously a steep perf penalty for making a copy of the attribute key every time [you use a Value attribute to wrap a simple attribute]

About the same perf penalty as wrapping the simple attribute in a Value.of()?

Yes. Steep is a bit hyperbolic, but these apis could end up on the hot path so maybe not

...rc/main/java/io/opentelemetry/api/incubator/common/ArrayBackedExtendedAttributesBuilder.java

jack-berg · 2025-11-18T22:29:47Z

...bator/src/main/java/io/opentelemetry/api/incubator/common/ArrayBackedExtendedAttributes.java

+    if (isArrayType(key.getType())) {
+      T value = (T) super.get(key);
+      if (value == null) {
+        // Check if there's a VALUE with the same key that contains an empty array


I don't understand this bit. Is there special handling of empty somewhere?

this is for

* <p>Further, if {@code put(ExtendedAttributeKey.valueKey("key"), Value.of(emptyList()))} was * called, then * * <ul> * <li>{@code get(ExtendedAttributeKey.stringArrayKey("key"))} * <li>{@code get(ExtendedAttributeKey.longArrayKey("key"))} * <li>{@code get(ExtendedAttributeKey.booleanArrayKey("key"))} * <li>{@code get(ExtendedAttributeKey.doubleArrayKey("key"))} * </ul> * * <p>all return an empty list (as opposed to {@code null}).

tested here:

@Test void emptyValueArrayRetrievedAsAnyArrayType() { ExtendedAttributes attributes = ExtendedAttributes.builder() .put(valueKey("key"), Value.of(Collections.emptyList())) .build(); assertThat(attributes.get(stringArrayKey("key"))).isEmpty(); assertThat(attributes.get(longArrayKey("key"))).isEmpty(); assertThat(attributes.get(doubleArrayKey("key"))).isEmpty(); assertThat(attributes.get(booleanArrayKey("key"))).isEmpty(); }

jack-berg · 2025-11-18T22:32:55Z

...rc/main/java/io/opentelemetry/api/incubator/common/ArrayBackedExtendedAttributesBuilder.java

+        switch (attributeType) {
+          case STRING_ARRAY:
+            List<String> strings = new ArrayList<>();
+            for (Value<?> v : arrayValues) {


If we're interested in premature performance optimization, there's probably a way to to merge this with attributeType function to iterate only once.

I'd say only pursue if it ends up making the code more concise with the perf improvement.

I think it would require optimistically creating the array as we loop through and potentially throwing it away?

trask force-pushed the complex-attrs-c-impl branch from f91ab1f to 6e1c6e7 Compare November 5, 2025 21:34

trask force-pushed the complex-attrs-c-impl branch 2 times, most recently from cbdcc32 to 2b69000 Compare November 8, 2025 00:09

anuraaga mentioned this pull request Nov 12, 2025

Migrate generative AI semantic conventions to OTel 1.37.0 open-telemetry/opentelemetry-java-instrumentation#15268

Open

trask added 14 commits November 13, 2025 10:53

Prototype: Complex attributes (Option C - minimal)

5e889a8

Remove String, Value<?> overload

4a2c048

Add javadoc explaining coersion

3b8e35f

more javadoc

04937c0

more javadoc

73466c8

more

1958768

Complex Attributes - incubating implementation

e4308cf

Deprecation

5f342e2

More implementation

8c40374

updates

7d49b5e

javadoc

d3f9dbe

tests

08e6e0c

javadoc

c7824e1

fix

26a3413

trask force-pushed the complex-attrs-c-impl branch from 4da140a to 26a3413 Compare November 13, 2025 19:32

Add a missing test

d83ff5d

trask commented Nov 13, 2025

View reviewed changes

api/all/src/main/java/io/opentelemetry/api/common/ArrayBackedAttributesBuilder.java Outdated Show resolved Hide resolved

trask added 2 commits November 13, 2025 14:32

Apply suggestion from @trask

10d6e02

codecov

198faa2

trask marked this pull request as ready for review November 13, 2025 23:23

trask requested a review from a team as a code owner November 13, 2025 23:23

trask mentioned this pull request Nov 14, 2025

Prototype: Complex attributes (Option C) #7813

Closed

jkwatson approved these changes Nov 17, 2025

View reviewed changes

lmolkova mentioned this pull request Nov 18, 2025

Stabilize new attribute value types open-telemetry/opentelemetry-specification#4710

Open

Implement limits

4386c8c

trask force-pushed the complex-attrs-c-impl branch from f27638a to 4386c8c Compare November 18, 2025 22:27

jack-berg reviewed Nov 18, 2025

View reviewed changes

trask added 5 commits November 18, 2025 14:43

simplify putValue implementation

575535d

initialize array lists with correct size

f1ffad8

Add test for non-existent array type to improve code coverage

6480d0e

spotless

22e857d

Move warning to where users will see it

b91d3bb

Complex attributes incubating implementation #7814

Are you sure you want to change the base?

Complex attributes incubating implementation #7814

Uh oh!

Conversation

trask commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

jkwatson left a comment

Choose a reason for hiding this comment

Uh oh!

jack-berg commented Nov 17, 2025

Uh oh!

trask commented Nov 18, 2025

Uh oh!

trask commented Nov 18, 2025

Uh oh!

jack-berg commented Nov 18, 2025

Uh oh!

trask commented Nov 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

trask commented Nov 5, 2025 •

edited

Loading

codecov bot commented Nov 6, 2025 •

edited

Loading