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
When FastAPI runs a non-async dependency or handler, it puts it into an internal thread pool so that the async execution doesn't get blocked. I'm pretty sure that the trace context doesn't get propagated into that thread pool (see Sean's problem in #88), which is obviously undesirable. It'd be nice if this worked seamlessly instead.
We probably need a new context (or just extend the existing no-bugs AsyncContext in xraysink) which can hook into FastAPI's specific non-async dispatch in order to add the trace context to those calls. This work could be fairly large!
Possibly related, but probably different piece of work: Support calling an instrumented sync function from async code (eg. see aws/aws-xray-sdk-python#164 (comment))
When FastAPI runs a non-async dependency or handler, it puts it into an internal thread pool so that the async execution doesn't get blocked. I'm pretty sure that the trace context doesn't get propagated into that thread pool (see Sean's problem in #88), which is obviously undesirable. It'd be nice if this worked seamlessly instead.
We probably need a new context (or just extend the existing no-bugs
AsyncContext
inxraysink
) which can hook into FastAPI's specific non-async dispatch in order to add the trace context to those calls. This work could be fairly large!Possibly related, but probably different piece of work: Support calling an instrumented sync function from async code (eg. see aws/aws-xray-sdk-python#164 (comment))
encode/starlette#1258 may be a helpful starting point
The text was updated successfully, but these errors were encountered: