[FastAPI] Add TC for non-async methods #514
Conversation
Ferenc-
left a comment
Ferenc-
left a comment
There was a problem hiding this comment.
Looks good, only the usage of async_tracer instead of tracer could be perhaps improved.
GSVarsha
force-pushed
the
non-async-fastapi
branch
from
6a13058 to
c740860
Compare
|
|
GSVarsha
force-pushed
the
non-async-fastapi
branch
2 times, most recently
from
653e513 to
8802291
Compare
Span order was the issue. Used span filters to resolve the same. |
Ferenc-
left a comment
Ferenc-
left a comment
There was a problem hiding this comment.
Looks good. Now that we are here, could we also add some TCs, that make explicit use of from fastapi.concurrency import run_in_threadpool?
I think that might be the area where we could pontentially find limitations pertaining to the tracer's thread boundary, and where we might have to document something.
pvital
left a comment
pvital
left a comment
There was a problem hiding this comment.
It looks good to me, but your commit message is a bit messy.
Could you rebase and reword your commit message before merging it, please?
GSVarsha
force-pushed
the
non-async-fastapi
branch
from
8802291 to
e31aabd
Compare
Signed-off-by: Varsha GS <varsha.gs@ibm.com>
Signed-off-by: Varsha GS <varsha.gs@ibm.com>
GSVarsha
force-pushed
the
non-async-fastapi
branch
from
63e511f to
ebd54d1
Compare
|
Observation: We are unable to trace non-async functions across thread boundaries only with the explicit use of the coroutine Opened a PR to document this limitation |
Add a non-async path operation function that makes a complex non-asynchronous request to check if all the outgoing calls made by the request are properly traced.