Open lattwood opened 2 weeks ago
This was directly caused by #1989
Aside- what kind of commit title is test
?
User has to import opentelemetry and configure it to have this. This code executes only if the import succeeds which requires user to import and configure opentelemetry.
specifically this is the erroneous assumption, there are many ways the import can fail.
affected by this as well any estimate to resolve?
Seems like a straightforward issue to fix... Can we get some eyes on this one? @sfc-gh-mkeller @sfc-gh-yuwang @sfc-gh-aling @sfc-gh-sghosh @sfc-gh-yixie @sfc-gh-aalam
thanks folks for drawing attention to this, we'll take a look.
Thanks for your bug report, this is very valuable input. Unfortunately, after further investigation this proves to be an issue specific to DataDog because by just including a clean opentelemetry-api
dependency does not reproduce this problem, which means that what they include is not the "full" opentelemetry-api (see the fact that in opentelemetry-api the tracecontext is available see here and here and here(here you can see the exception being thrown).
This is still a problem that Snowflake can fix by catching all the exceptions there, though that is not the right way of writing code, since you cannot have a catch all exception every time you call any API that should not return an exception, but Snowflake will do it anyway since tracing should not break your data aplication.
@sfc-gh-bdrutu Based on what you've said, I've taken the liberty of opening an issue on the ddtrace-py repository- https://github.com/DataDog/dd-trace-py/issues/11407
I would expect that opentelemetry integration would be done via this- https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation
and not via a hack in the actual library that breaks the driver for anyone that has opentelemetry installed but not in-use.
I hope that this issue results in that change being reverted, and the original requestor of the feature gets this done properly in the open-telemetry project.
Based on my experience with OpenTelemetry in different environments, OpenTelemetry was designed with flexibility in mind, supporting scenarios where telemetry is directly embedded within libraries, rather than requiring separate instrumentation libraries.
I'm facing this as well. Specifically, incompatible with https://github.com/DataDog/datadog-lambda-python/releases/tag/v6.99.0 Was this introduced by https://github.com/snowflakedb/snowflake-connector-python/commit/0d005199204a90082ec22b63008bb6e44500ec44?
@bogdandrutu you literally have the same bio on your two accounts.
Since I was unable to reproduce the issue I'd really like someone with the issue to test drive the change I proposed in #2106 . Please don't forget to let us know if it worked properly!
Python version
N/A
Operating system and processor architecture
N/A
Installed packages
What did you do?
I used the driver w/ Datadog APM, which installs the opentelemetry packages that are used as the check to see if we can inject trace context.
With DataDog, this gets happens on every query, and it fails to run.
This is because the only exception caught is ModuleNotFoundError, and opentracing is throwing a ValueError which isn't getting caught.
(please forgive any typos, I copied the backtrace from a screenshot)
What did you expect to see?
I would expect that opentelemetry integration would be done via this- https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation
and not via a hack in the actual library that breaks the driver for anyone that has opentelemetry installed but not in-use.
I hope that this issue results in that change being reverted, and the original requestor of the feature gets this done properly in the open-telemetry project.
Can you set logging to DEBUG and collect the logs?