logfire

logfire copied to clipboard

Description

Posting from a request from slack.

It appears that when using an async engine in SQLAlchemy+ psycopg3, timing information is lost/not correct on logfire. See the two screenshots below: one uses an async engine (the one with 1ms/0ms timings), the other uses the sync engine (correct timings)

I would expect to see timing information for queries done using the async varieties of these packages

Python, Logfire & OS Versions, related packages

logfire="0.28.0"
platform="macOS-14.1.1-arm64-arm-64bit"
python="3.12.1 (main, Dec  7 2023, 20:45:44) [Clang 15.0.0 
(clang-1500.0.40.1)]"
[related_packages]
requests="2.31.0"
pydantic="2.7.1"
fastapi="0.110.2"
protobuf="4.25.3"
rich="13.7.1"
opentelemetry-api="1.24.0"
opentelemetry-exporter-otlp-proto-common="1.24.0"
opentelemetry-exporter-otlp-proto-http="1.24.0"
opentelemetry-instrumentation="0.45b0"
opentelemetry-instrumentation-asgi="0.45b0"
opentelemetry-instrumentation-asyncio="0.45b0"
opentelemetry-instrumentation-dbapi="0.45b0"
opentelemetry-instrumentation-fastapi="0.45b0"
opentelemetry-instrumentation-grpc="0.45b0"
opentelemetry-instrumentation-jinja2="0.45b0"
opentelemetry-instrumentation-psycopg="0.45b0"
opentelemetry-instrumentation-redis="0.45b0"
opentelemetry-instrumentation-sqlalchemy="0.45b0"
opentelemetry-proto="1.24.0"
opentelemetry-sdk="1.24.0"
opentelemetry-semantic-conventions="0.45b0"
opentelemetry-test-utils="0.45b0"
opentelemetry-util-http="0.45b0"

According to Slack, @samuelcolvin is looking to this issue.

See https://github.com/open-telemetry/opentelemetry-python-contrib/issues/2486 - the fix is not trivial, but we'll try to submit a PR soon.

Since this problem is on OTel side, I'll be closing this issue.

You can watch the issue on OTel side: https://github.com/open-telemetry/opentelemetry-python-contrib/issues/2486