DD_TRACE_EXPAND_ROUTE_TEMPLATES_ENABLED does not expand http.route tag, only resource_name

[majorgreys]

Description

When DD_TRACE_EXPAND_ROUTE_TEMPLATES_ENABLED=true is set, the resource_name is correctly expanded (e.g., {controller} is replaced with the actual controller name), but the http.route span tag retains the raw ASP.NET route template without expansion.

Expected Behavior

Both resource_name and http.route should reflect the expanded route when DD_TRACE_EXPAND_ROUTE_TEMPLATES_ENABLED=true is enabled. For example, if the route template is api/{controller}/{id}, both attributes should show api/users/{id}.

Actual Behavior

• resource_name: GET /api/users/{id} (expanded correctly)
• http.route: api/{controller}/{id} (NOT expanded)

This causes the Datadog endpoints page to display duplicate entries because it uses http.route for the display path. Multiple distinct controllers sharing the same route template pattern (e.g., api/{controller}/{id}) all appear as one endpoint.

Root Cause

In AspNetMvcIntegration.cs, HttpRoute is set to the raw routeUrl (route.Url) before any expansion:

tags.AspNetRoute = routeUrl;
// ...
rootAspNetTags.HttpRoute = routeUrl;

The expandRouteTemplates parameter is only passed to CalculateResourceName() for computing the resource name — it is never applied to the http.route tag.

The same pattern exists in AspNetWebApi2Integration.cs and AspNetCoreDiagnosticObserver.cs.

Reproduction

1. Create an ASP.NET app with a generic route like api/{controller}/{id} that maps to multiple controllers
2. Set DD_TRACE_EXPAND_ROUTE_TEMPLATES_ENABLED=true
3. Observe that resource_name has the controller expanded but http.route still contains {controller}

Impact

The Datadog APM endpoints page uses http.route for the displayed path and resource_name for the copied name. This inconsistency causes:

• Apparent duplicate endpoints in the UI (many controllers collapse into one {controller} entry)
• Confusing copy behavior where the copied value differs from what is displayed

[andrewlock]

@majorgreys This is... unfortunate 😅

The interesting thing is that this approach was very explicit - the expected behaviour in terms of the data we're sending is what happens today 😬

The reasoning is that the "raw" route, api/{controller}/{id}, is the actual correct value. That is the route that the app is using. It is the route that open telemetry reports. If the customer wants to know which route in their application is handling the request that's the value they need, not the interpolated value.

All of which is to say - if we change this, customers are losing information that they previously had.

The Datadog APM endpoints page uses http.route for the displayed path and resource_name for the copied name.

Probably a silly question but... should it? These issues kind of sound like they could be fixed by the backend/frontend (which would then fix them for all users too, not just the small number that update to the latest tracer)?