Sentry does not get rest api title correct on performance metric transaction when using Microsoft.AspNetCore.Mvc.Versioning

[tlf30]

Package

Sentry.AspNetCore

.NET Flavor

.NET Core

.NET Version

6.0.4

OS

Windows

SDK Version

3.16.0

Self-Hosted Sentry Version

22.2.0

Steps to Reproduce

1. Create a controller using Microsoft.AspNetCore.Mvc.Versioning
   Example:

[Authorize]
[ApiController]
[ApiVersion("1")]
[Route("api/v{version:apiVersion}/[controller]")]
[Produces("application/json")]
public class AuthController : Controller 
{
    [MapToApiVersion("1")]
    [HttpPost]
    [AllowAnonymous]
    [Route("Login")]
    [ProducesResponseType(typeof(AuthResponse), StatusCodes.Status200OK)]
    [ProducesResponseType(typeof(AuthDeniedResponse), StatusCodes.Status401Unauthorized)]
    public IActionResult Login()
    {
        return Ok(); //TODO: Do something
    }
}

2. Perform request against endpoint
   

Expected Result

It is expected that the correct version is inserted into the request metadata sent back to the server.

Actual Result

[mattjohnsonpint]

Thanks for raising this. I belive @lucas-zimerman might have some input on this one?

[lucas-zimerman]

Thanks for raising this. I belive @lucas-zimerman might have some input on this one?

It has been like that for a while.
One way this could be fixed is by using the IApiVersioningFeature to retrieve the correct version number and replace the {version:ApiVersoin}, but that will generate a new group of transactions to the users once they update the SDK with this feature.

[tlf30]

Perhaps it would be possible to make it configurable from the application using sentry options?
In my use case, it would be nice to have the version id populated to create separated transaction groups, but I can also understand where others would wish to keep the existing behavior, and/or have the desire to keep their existing transaction groups. Perhaps the default can be to keep the existing behavior with a way to enable resolving the api version as an option.

I have not looked under the hood of api versioning, but I am aware that for dotnet 6, some things with the api version have changed and it is now no longer a Microsoft project, more info here: dotnet/aspnet-api-versioning#808. And currently there is no release yet for dotnet 6, yet many people (including myself) are using the 5.x version for dotnet 6 without issues. Just something to keep in mind if adding integration for.

Perhaps if adding integration, it could be included in a separate package, this would allow for not including the api versioning as a dependency for projects that do not use it. It could also be the means for configuring that you would like to resolve the api version. The old behavior would be maintained if the dependency is not included, but with the dependency then the api version would be resolved. Just another idea for how to address the issue.

Thank you,
Trevor

[mattjohnsonpint]

Yes, this may be considered a breaking behavioral change, but my thinking is this:

• If you're not using Microsoft.AspNetCore.Mvc.Versioning, then there's not breaking change for you.
• If you are using, then you probably want this bug to be fixed, even if that affects your groupings in Sentry.

So, let's get it fixed.