-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Same trace ID for multiple requests with large bodies in Starlette #2852
Comments
AFAIU you are getting multiple spans for the same request, so why you would want multiple trace ids for the same request? |
I guess the description wasn't clear enough 😅 Does that make things clearer? |
The threshold comes from Uvicorn, it is the limit where a request body is split into multiple ASGI messages. |
Yeah, that was I supposed it to be. My point is that these are the same request |
Yes all the ASGI messages that carry the body are the same request, but here I am sending multiple requests concurrently, each with a set of messages. In that case, the same trace id is used across different requests. |
Ah! Thanks for the explanation |
This seems to come down to encode/uvicorn#2167. |
Should be a problem on AsyncIO itself: encode/uvicorn#2167 (comment) |
Describe your environment
OS: Ubuntu
Python version: 3.11
Package version: 0.48b0/1.27.0
What happened?
I have been observing that multiple requests' spans are assigned to the same trace ID, thus when viewing traces the spans are mixed together, even though they should be in separate contexts.
After some digging, I found this happens when the request body is large (>=65536 bytes)
Steps to Reproduce
A simple instrumented Starlette app:
With the app running, then launch:
Expected Result
When the size of the body is not too large (e.g.
body_size_ok
in the MRE), each request is assigned its own trace ID. It should be the same for larger requests.Actual Result
The same trace IDs get reused for multiple (concurrent) requests.
Additional context
When running the app with Uvicorn, I noticed that the issue only happens with the
loop="asyncio"
option, not withloop="uvloop"
. I didn't dig any further into it, maybe it's just the threshold size that changes? Or perhaps that is where the issue comes from? 🤷Would you like to implement a fix?
None
The text was updated successfully, but these errors were encountered: