Skip to content

Add some helpful logging attribute methods #7089

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

breedx-splk
Copy link
Contributor

It is tedious and hurts readability to have the various attribute key methods sprinkled in user code. This allows users to simply pass the string containing the key name, which is what users want 99.92% of the time.

@breedx-splk breedx-splk requested a review from a team as a code owner February 7, 2025 22:28
@tealamore
Copy link

The code looks good to me. Is there anything we should do to address the build failing?

Copy link

codecov bot commented Feb 10, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.85%. Comparing base (19650df) to head (de8cf9d).
Report is 36 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #7089      +/-   ##
============================================
- Coverage     89.86%   89.85%   -0.01%     
- Complexity     6613     6618       +5     
============================================
  Files           740      740              
  Lines         19991    19996       +5     
  Branches       1966     1966              
============================================
+ Hits          17964    17967       +3     
- Misses         1437     1443       +6     
+ Partials        590      586       -4     

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

Copy link
Member

@jack-berg jack-berg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect you intentionally include boxed types instead of primitives to allow for null, but I think if we want to settle accepting nullable attributes, we should do it holistically: #4336

@breedx-splk
Copy link
Contributor Author

I suspect you intentionally include boxed types instead of primitives to allow for null, but I think if we want to settle accepting nullable attributes, we should do it holistically: #4336

Yeah exactly, because I think its safe to pass null and it effectively becomes a no-op.

If we do make these primitives, it forces the call site (user code) to have to deal with the nulls in advance...which is good for us because its simpler and takes null out of the equation...but I think it weakens the usability and convenience, which is the whole point.

I don't feel super strongly about it anyway though.

@tealamore
Copy link

This line in the spec is a bit ambiguous

Attribute values of null are not valid and attempting to set a null value is undefined behavior.

I can see it meaning that we shouldn't accommodate users submitting null values or perhaps we can take null values, but that the exported values may change and it isn't well documented

@trask
Copy link
Member

trask commented Feb 13, 2025

I think we should stay consistent with the setAttribute methods in Span

@jack-berg jack-berg merged commit ee731aa into open-telemetry:main Feb 24, 2025
27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants