Clearer exceptions when accessing versioned OpenAPI documents that do not exist

[sander1095]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

When I set up ASP.Versioning v10 like below, and access an OpenAPI version document that doesn't exist (openapi/v10.json for example), an exception is thrown:

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
      An unhandled exception has occurred while executing the request.
      System.InvalidOperationException: This service provider doesn't support keyed services.
         at Microsoft.Extensions.DependencyInjection.ServiceProviderKeyedServiceExtensions.GetKeyedService(IServiceProvider provider, Type serviceType, Object serviceKey)
         at Microsoft.Extensions.DependencyInjection.KeyedServiceContainer.GetKeyedService(Type serviceType, Object serviceKey) 
         at Microsoft.Extensions.DependencyInjection.ServiceProviderKeyedServiceExtensions.GetKeyedService[T](IServiceProvider provider, Object serviceKey)
         at Microsoft.AspNetCore.Builder.OpenApiEndpointRouteBuilderExtensions.<>c__DisplayClass0_0.<<MapOpenApi>b__0>d.MoveNext()
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Http.Generated.<GeneratedRouteBuilderExtensions_g>F0399B8B15BE443123F4BECEE84B112C1912EE3F44D9DDD7BFA38E371FB917343__GeneratedRouteBuilderExtensionsCore.<>c__DisplayClass2_0.<<MapGet0>g__RequestHandler|5>d.MoveNext()       
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
         at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
         at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

The code (See https://github.com/sander1095/openapi-versioning/blob/v10/v10/controllers/queryheader-versioning-openapi/Program.cs for more)

using Asp.Versioning;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

builder.Services.AddApiVersioning(options =>
{
    options.ReportApiVersions = true;

    options.DefaultApiVersion = new ApiVersion(1, 0);

    options.AssumeDefaultVersionWhenUnspecified = false;

    options.ApiVersionReader = new QueryStringApiVersionReader("api-version");

})
.AddApiExplorer(options =>
{
    options.GroupNameFormat = "'v'VVV";
})
.AddMvc()
.AddOpenApi();

var app = builder.Build();

app.MapOpenApi().WithDocumentPerVersion();

app.MapControllers();

app.Run();

Describe the solution you'd like

When accessing a non-existing real endpoint (like api/scores) it returns a 400 bad request. Similar behavior for the OpenAPI document would be desirable. Otherwise, a clearer exception :)

Additional context

Due to the exception being the same, perhaps this is related to #1176

[commonsensesoftware]

Yeah, this is a little yucky and it's not 100% clear to me how to make this better without making some assumptions. The case where I've seen this happen is when you try to navigate to the openapi.json file directly and the version string in the URL doesn't match. The process internally does some interception and returns the expect result if the version matches. If it doesn't, it forwards on to the real IServiceProvider. That is the source of this exception. The tricky part is trying to understand if the key should match and provide a better message. If you're going through a UI like Scalar, you should never see this.

[sander1095]

Hey Chris!

I think I want to take this back a step and compare the behavior to ASP.Versioning V8.

When retrieving an OpenAPI document that doesn't exist in ASP.Versioning, the server returns HTTP 404 with No OpenAPI document with the name 'v3' was found.

When doing the same with ASP.Versioning V10: HTTP 500, with an exception: InvalidOperationException: This service provider doesn't support keyed services.

This is a breaking change; I would like ASP.Versioning V10 to have the same behavior.

I think your answer might remain the same either way, but I think my intent and origin of this issue is a bit more clear with this background information.

[commonsensesoftware]

I'll take a deeper look. There's a chance there is a casing issue. It could also be related to #1178, which is a different issue, but will produce a similar error message.