[BUG]: Starlette/FastAPI integration generates high-cardinality traces for pre-flight OPTIONS requests #14321
Description
Package Name
starlette
Package Version(s)
No response
Describe the goal of the feature
🐞 Problem
When using ddtrace with FastAPI (or Starlette), CORS pre-flight requests (i.e. OPTIONS requests issued by browsers) are traced with the fully resolved path, including route parameters. This leads to high-cardinality metrics and noisy traces.
💡 Example
Consider a FastAPI route:
from fastapi import FastAPI
app = FastAPI()
@app.get("/users/{id}")
async def get_user(id: str):
return {"id": id}When a browser makes a GET /users/12345 request, it first sends a pre-flight request:
OPTIONS /users/12345
Access-Control-Request-Method: GET
...
The trace for this pre-flight request is recorded as:
OPTIONS /users/12345
This includes the actual user ID (12345), even though the route is defined as /users/{id}. Each unique id generates a separate trace, inflating the cardinality of metrics unnecessarily.
✅ Expected Behavior
- The integration should detect pre-flight requests by checking the Access-Control-Request-Method header.
- It should resolve the intended route using the indicated method (e.g.,
GET) and path. - The trace should be recorded using the normalized route path, such as:
OPTIONS /users/{id}
Is your feature request related to a problem?
No response
Describe alternatives you've considered
No response
Additional context
No response