You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe your environment. I am using a Python Azure Function where I use SQLAlchemy with async engine using postgres+asyncpg to make database queries based on the content of the request. I used the steps in their documentation to make it work, but and I added 'sqlalchemy' to trace_integrations instead of 'requests'.
from opencensus.extension.azure.functions import OpenCensusExtension
from opencensus.trace import config_integration
config_integration.trace_integrations(["sqlalchemy"])
OpenCensusExtension.configure()
Steps to reproduce.
Try integrating sqlalchemy in a Python Azure Function with asyncpg and an async engine of SQLAlchemy using async sessions.
What is the expected behavior?
I would like to see how long each query takes and some additional properties but I get them duplicated as seen below.
What is the actual behavior?
Strange thing is that one is the child of a span that already has a trace for that query.
Additional context.
I am not sure if this library is not prepared for async or it is because of sessions, connections, etc.
For illustration I made this with pg_sleep, but it is the same with "normal" queries.
The text was updated successfully, but these errors were encountered:
Describe your environment. I am using a Python Azure Function where I use SQLAlchemy with async engine using postgres+asyncpg to make database queries based on the content of the request. I used the steps in their documentation to make it work, but and I added 'sqlalchemy' to trace_integrations instead of 'requests'.
Steps to reproduce.
Try integrating sqlalchemy in a Python Azure Function with asyncpg and an async engine of SQLAlchemy using async sessions.
What is the expected behavior?
I would like to see how long each query takes and some additional properties but I get them duplicated as seen below.
What is the actual behavior?
Strange thing is that one is the child of a span that already has a trace for that query.
Additional context.
I am not sure if this library is not prepared for async or it is because of sessions, connections, etc.
For illustration I made this with pg_sleep, but it is the same with "normal" queries.
The text was updated successfully, but these errors were encountered: