fix: support newer OpenTelemetry SDK #1791
Conversation
tonyandrewmeyer
left a comment
tonyandrewmeyer
left a comment
There was a problem hiding this comment.
I still don't really like that we're using private attributes, since it seems like it keeps the likelihood of problems like this happening. If we pinned to specific versions we could avoid that, but that's generally bad practice for libraries.
It seems like this is worth doing now to get a quick fix out and we can figure out if there's something better we can do longer term afterwards.
I haven't managed to try this out yet - will finish that first thing tomorrow I hope.
james-garner-canonical
left a comment
james-garner-canonical
left a comment
There was a problem hiding this comment.
+1 on figuring out something else for the long term, but agreed on getting this fix in now
|
I don't think we should merge this workaround, but rather figure out a way of not using those private attributes. Your option 2 in the chat sounds reasonable to me: "use globals--record our exporter when we set the library-global tracer provider, and get a reference to own exporter from own global". Let's discuss further in daily and see if we can come to consensus. |
4 participants
I'm proposing this as a hot-fix to support both older and newer style of the OpenTelemetry SDK.
Upstream change that broke our code: open-telemetry/opentelemetry-python#4580