Span should have a getter for attributes

[codeboten]

Currently there are multiple places in the code that make the assumption that a Span has an attributes attribute, this is not always the case.

The solution could be to implement an attributes property on the Span interface, or we could implement a separate getter method.

[aravinsiva]

I can take this on if help is still needed.

[aravinsiva]

For this issue do all instances of attributes.get() need to be refractored to the new getter method (i.e. span.get_attribute(key)?

[carlosalberto]

The solution could be to implement an attributes property on the Span interface, or we could implement a separate getter method.

Would this be in the main OTel API? Asking cause we don't have that one in the other languages (they do exist in the SDK though).

[aravinsiva]

No right now just implementing in the sdk but I can add it ton the API if need be

[codeboten]

Tthe main problem that was being captured by this issue is that many instrumentations are calling out the a span's attributes directly. This is fine for access the SDK's implementation of a Span but that's not the case for the api, which has no attributes variable. There's a definition for a setter but not for a getter in the API for attributes, and maybe there should be.

[toumorokoshi]

Tthe main problem that was being captured by this issue is that many instrumentations are calling out the a span's attributes directly. This is fine for access the SDK's implementation of a Span but that's not the case for the api, which has no attributes variable. There's a definition for a setter but not for a getter in the API for attributes, and maybe there should be.

It doesn't necessarily needed to be added to the API, but it does requires the need for an SDK-specific noop span that returns nothing for the getter.

That said I support more explicitly providing a "Span" object in the API, and having an attribute getter with that.

[aabmass]

@aravinsiva, I think you discussed this (or was it something different?) in the Spec SIG last week. Did you come to any conclusion if this should be added to the Spec API?

[aravinsiva]

It was something different. Last week in the spec SIG I was talking about default span attributes in OT-js. If you feel like this is something that should be brought up in the next spec SIG I would be happy to do that.

[lzchen]

Does the existence of attributes in span creation imply that whatever implementation of Span is used, attributes should be an attribute? How is it possible to enforce attributes within an interface (I don't think you can?). If not, I think we'll need to use getter methods in the API, in case the user is the default span implementation.

Also, wouldn't this problem occur for all api level properties of the span? (events, links, spankind)

[aravinsiva]

After speaking to the specification SIG it seems as though the API was designed to be write only it and this is intentional. As a result we may need to develop another approach to solving the this issue. As @lzchen mentioned this is something that also occurs with events, links and spankind attributes. Since this does not seem to be getting raised to the spec level we may need to detemermined another approach to solving this issue. @codeboten suggested maybe looking for all instances of the attributes value being accessed and seeing if it exists. This is however a likely bad solution which won't enforce this down the line. As a result is there any solution to this issue as of right now? If so I would love to hear your guy's thoughts.

[lzchen]

That said I support more explicitly providing a "Span" object in the API, and having an attribute getter with that.

I think this would be the easiest, least intrusive solution. Even though "get" is not defined in the API specs, the issue seems language specific, and some other languages don't seem to be using a no-op span.