I'm not sure the current behavior is really a bug, this is what I would expect to happen.

Could you explain a little more the use case for changing the behavior?

imagine you're running some scientific computing code that involves randomness and you want to persist the seed for reproducibility. if your teammates run the instrumented code with the same seed (to check your results), they'll generate traces with the same ID - is that a good thing? minimally, I can imagine it'd be inconvenient, because each run would no longer be uniquely identifiable from a tracing perspective (you'd need to know out-of-band information like the timestamp)

while I think it makes sense to be able to control the seed of the OTel random generator, I don't think it should use the global seed.

I'm not sure the current behavior is really a bug, this is what I would expect to happen.

Could you explain a little more the use case for changing the behavior?

In some scenarios, such as model performance evaluation, we prefer the split between training and testing data to be random. By setting a fixed random seed, we can ensure that each model uses the same dataset for training and validation, enabling fair comparisons.

In this context, integrating OpenTelemetry can lead to the duplication of traceId and spanId if the application is restarted.

Here’s a demo:

import uvicorn
from fastapi import FastAPI, HTTPException
from logging import getLogger

_logger = getLogger(name)

def init():
import random
random.seed(10)

app = FastAPI()

@app.get("/health")
async def health_check():
return {"data": "ok"}

@app.get("/evaluation")
async def evaluation():
# Randomly generate a list of test numbers
random_numbers = random.sample(range(1, 101), 10)
'''
Other operations
test model 1
test model 2
'''
return {"data": {"score": 0.6}}

if name == "main":
init()
uvicorn.run(app, host="0.0.0.0", port=8000)
In this demo, when accessing the /evaluation endpoint, the generated traceId is 164207228320579316746596838417247989971, and the spanId is 273610340023782072, with the span name being /evaluation.

After restarting the application (due to an update or a manual restart), accessing the /health endpoint generates the same traceId 164207228320579316746596838417247989971 and spanId 273610340023782072. However, the span name has changed to /health, which is clearly incorrect.