x-ms-version is not being read in production!?

[elibroftw]

I don't know why but after deploying my app to production in Azure, the x-ms-version is being disregarded and the 1.0 of my API is being used when the client I wrote is asking for 2.0. When I test with my app running in release locally, the API works as desired.

[commonsensesoftware]

Do you have a repro, link, or, at least, the configuration setup that you can share? If the client asks for 2.0 and you're getting 1.0, some is definitely amiss. That should be impossible when an explicit version is requested. There is no fallback logic unless something else has been changed in the routing.

[elibroftw]

it's being completely ignored. It's not even returning a 501 when the version does not exist! it's as if the versioning code is not even being run even though the DLLS are there...
my code is a private repo but I'm wondering how this is even possible. I'll post snippets.

[commonsensesoftware]

Just the API Versioning configuration would likely provide quite a bit of insight.

[elibroftw]

Program.cs

builder.Services.AddApiVersioning(options => {
    options.DefaultApiVersion = new ApiVersion(1, 0);
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.ApiVersionReader = new HeaderApiVersionReader("x-ms-version");
    options.ReportApiVersions = true;
    options.UnsupportedApiVersionStatusCode = 501;
})
    // format the version as "'v'major[.minor][-status]"
    .AddApiExplorer(options => {
        options.GroupNameFormat = "'v'VVV";
    });

PaymentController.cs

Both these controllers are for /payment/invoice

[Route("[controller]/[action]")]
[ApiController]
[Authorize]
[ApiVersion(1.0)]
public class PaymentController : ControllerBase {

[HttpGet]
public async Task<ActionResult<string>> Invoice(string payee) {
    var user = User.FindFirstValue(ClaimTypes.Email);
    var userCurrency = User.FindFirstValue("Currency"); // saved from Currency enum so no need to check
    //var userLang = User.FindFirstValue("Language"); // TODO
    if (user == null || userCurrency == null) return Unauthorized($"Got user = {user} currency = {userCurrency}");
    try {
        return (await _paymentService.CreatePaymentIntentAsync(user, payee)).PaymentIntent;
    } catch (Exception ex) {
        return BadRequest(ex.Message);
    }
}

[HttpGet("/payment/invoice")]
[ApiVersion(2.0)]
public async Task<ActionResult<PaymentSheetProps>> InvoiceV2(string payee) {
    var user = User.FindFirstValue(ClaimTypes.Email);
    var userCurrency = User.FindFirstValue("Currency"); // saved from Currency enum so no need to check
    //var userLang = User.FindFirstValue("Language"); // TODO
    if (user == null || userCurrency == null) return Unauthorized($"Got user = {user} currency = {userCurrency}");
    try {
        return await _paymentService.CreatePaymentIntentAsync(user, payee);
    } catch (Exception ex) {
        return BadRequest(ex.Message);
    }
}

}

[elibroftw]

I think this is an issue with azure since it shows "degraded" and "Deployment Progress Deadline Exceeded." Probably was not a good idea to risk using containers... Yep turns out the container has not been updated since 3/6!!! Visual Studio never reported this issue what the hell.

[commonsensesoftware]

As I recall, you can use ActionNameAttribute to override the action name without changing the route template. [ActionName(nameof(Invoice))] on InvoiceV2 should yield the template Payment/Invoice for both actions.

You also need to be careful when you interleave versions. [ApiVersion] has a different affect on an action. I suspect you meant something like:

[Authorize]
[ApiController]
[ApiVersion(1.0)]
[ApiVersion(2.0)]
[Route("[controller]/[action]")]
public class PaymentController : ControllerBase
{
    [HttpGet] // implicitly maps to 1.0, but you can use [MapToApiVersion(1.0)]
    public async Task<ActionResult<string>> Invoice(string payee) {}

    [HttpGet]
    [MapToApiVersion(2.0)]
    [ActionName(nameof(Invoice))]
    public async Task<ActionResult<PaymentSheetProps>> InvoiceV2(string payee) {}
}

You can use [ApiVersion] on an action, but it affects the collation. This can be confusing when you interleave. [ApiVersion] directly on an action is usually not what you want - but maybe. This is Payments API and you have multiple actions within it. [ApiVersion] on an action makes the endpoint behave as though it were standalone.

[commonsensesoftware]

Bummer about the container. I advise against AssumeDefaultVersionWhenUnspecified = true unless it's for backward compatibility; that's what it was actually meant for. Even with a value of true, no fallback happens. Sending x-ms-version: 2.0 will only exactly match 2.0. You'd have to not send anything to implicitly match (e.g. assume) 1.0. This is one way to test your sanity.

👏🏽 kudos for using 501. I know it's not the default, but it's a pretty sane response status. 😃

[elibroftw]

I had to create a new azure deployment but this time I made sure to use the windows app service since its clear the containers were not recommended for a reason by the docs lol.

Thanks for the code review, although I initially did want the V2 to be limited to just that one action (so that the V2 page shows only the methods that have an explicit V2 implementation). I do need the default enabled for backwards compatibility as our mobile app on ios hasn't been updated in over a month and I don't plan on adding headers unnecessarily to the api.js file as I have made some ugly typo bugs already.