Open jonathanberthias opened 1 week ago
AFAIU you are getting multiple spans for the same request, so why you would want multiple trace ids for the same request?
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 😅 The issue is about multiple requests sharing the same trace id. I think the MRE illustrates what I mean, I am looking at what trace id is assigned inside the endpoint for many requests, and I expect each to have a different trace id. That is what I observe when the requests are small, or when I send the requests without adding some random sleep time.
Does that make things clearer?
The threshold comes from Uvicorn, it is the limit where a request body is split into multiple ASGI messages. https://github.com/encode/uvicorn/blob/47304d9ae76321f0f5f649ff4f73e09b17085933/uvicorn/protocols/http/flow_control.py#L7
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.
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
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? :shrug:Would you like to implement a fix?
None