TransactionNameProvider is never called for routed requests

[sentry-junior]

Summary

TransactionNameProvider is only invoked when the transaction name is empty (i.e. routing failed entirely). When ASP.NET Core routing resolves a route template successfully, the provider is silently skipped — making it impossible to partially materialize route parameters in the transaction name without writing a custom middleware.

Current behavior

In SentryTracingMiddleware, the TransactionNameProvider delegate is guarded by:

if (transaction.Name == string.Empty)
{
    transaction.Name = options.TransactionNameProvider?.Invoke(ctx) ?? ...;
}

Because routing resolves route templates like GET /api/v4/objects/{objectTypeName}/{objectId}/{operation}, transaction.Name is already populated before the provider is consulted. The delegate is never called.

Gap

There is no SDK-level hook that runs unconditionally after routing resolves and allows the transaction name to be rewritten. The full matrix of available hooks:

Hook	Status
TransactionNameProvider	Only fires when routing fails (name is empty) — unusable for routed requests
SetBeforeSendTransaction	transaction.Name is private set; NameSource has no setter — read-only
ITransactionProcessor / AddTransactionProcessor	Same constraint — name is not writable

The practical workaround today is to inject a custom ASP.NET middleware that runs after routing and rewrites the transaction name via SentrySdk.GetSpan() or similar. This is undiscoverable and fragile.

A related issue (#3106) was closed with the same custom-middleware workaround.

Options

Option A — Unconditional TransactionNameProvider invocation
Remove (or make optional) the if (transaction.Name == string.Empty) guard. Let the provider run on every routed request. A null return falls back to the SDK default. This is the smallest possible change and preserves backward compatibility for users who don't configure a provider.

Option B — Expose a mutable ITransactionContext in SetBeforeSendTransaction
Add a writable Name and NameSource to the type passed into SetBeforeSendTransaction / transaction processors. This is a broader API surface change but gives maximum flexibility.

Option C — Add a dedicated TransactionProcessor hook with mutation support
Introduce a post-routing pipeline hook (e.g. OnTransactionNameResolved) that receives the resolved route data and can return a replacement name.

Recommendation

Option A is the lowest-risk path: make TransactionNameProvider fire unconditionally and treat a null return as "keep the SDK default." This directly fixes the documented (but broken) use case with no breaking API change.

Action taken on behalf of a Sentry support escalation.

[linear-code]

NET-656

[jamescrosswell]

Hm, option 1 certainly seems the easiest... would involve reworking this code basically:

sentry-dotnet/src/Sentry.AspNetCore/SentryTracingMiddleware.cs

Lines 180 to 200 in 96d9d6c

	// If no Name was found for Transaction, then we don't have the route.
	if (transaction.Name == string.Empty)
	{
	var method = context.Request.Method.ToUpperInvariant();
	// If we've set a TransactionNameProvider, use that here
	var customTransactionName = context.TryGetCustomTransactionName();
	if (!string.IsNullOrEmpty(customTransactionName))
	{
	transaction.Name = $"{method} {customTransactionName}";
	tracer.NameSource = TransactionNameSource.Custom;
	}
	else
	{
	// Finally, fallback to using the URL path.
	// e.g. "GET /pets/1"
	var path = context.Request.Path;
	transaction.Name = $"{method} {path}";
	tracer.NameSource = TransactionNameSource.Url;
	}
	}

The coding change would be fairly trivial. My only concern is how/who would be affected by the behavioural change.

Previous behaviour

• TransactionNameProvider only runs if our middleware isn't able to resolve the route

New behaviour

• TransactionNameProvider always runs

It's entirely possible we have customers who have built code that relies on the previous behaviour so I think this would be a breaking change that we'd want to roll out in a major version bump with some proper comms around it.

[EricLuth]

I ran into this problem, where TransactionNameProvider isn't being called. I'd prefer Option A (always call - remove the guard), but I appreciate how this might affect existing customers.

An optional approach is add a new initialization property for OnlyHookTransactionNameProviderWhenUnresolved (or some better name) with a default of true. Customers can set to false if they want to hook unconditionally. This allows you to preserve existing customers while opening things up for others.

[jamescrosswell]

@EricLuth that's a good suggestion. Would give customers a fix in the short term whilst not breaking the behaviour for others... and gives us a smooth transition in the next major release (we could change the default but if that breaks things for some customers, they can always switch it back).