Skip to content

NullReferenceException in TryMatchModelVersion with OData + OpenAPI and only the default version #850

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
icnocop opened this issue Aug 3, 2022 · 6 comments

Comments

@icnocop
Copy link

icnocop commented Aug 3, 2022

Hi.

When I try to get swagger.json for an OData API which exposes only the default version, the following exception occurs:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Asp.Versioning.ApiExplorer.ODataApiDescriptionProvider.TryMatchModelVersion(ApiDescription description, IReadOnlyList`1 items, IODataRoutingMetadata& metadata) in E:\github\icnocop\aspnet-api-versioning-preview3-fixes\src\AspNetCore\OData\src\Asp.Versioning.OData.ApiExplorer\ApiExplorer\ODataApiDescriptionProvider.cs:line 198
   at Asp.Versioning.ApiExplorer.ODataApiDescriptionProvider.OnProvidersExecuted(ApiDescriptionProviderContext context) in E:\github\icnocop\aspnet-api-versioning-preview3-fixes\src\AspNetCore\OData\src\Asp.Versioning.OData.ApiExplorer\ApiExplorer\ODataApiDescriptionProvider.cs:line 120
   at Microsoft.AspNetCore.Mvc.ApiExplorer.ApiDescriptionGroupCollectionProvider.GetCollection(ActionDescriptorCollection actionDescriptors)
   at Microsoft.AspNetCore.Mvc.ApiExplorer.ApiDescriptionGroupCollectionProvider.get_ApiDescriptionGroups()
   at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GetSwagger(String documentName, String host, String basePath)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

I will create a PR with a sample project that can reproduce the issue.

I'm using the latest code from the dev/css/preview3-fixes branch with an ASP.NET Core web application targeting .NET Core 3.1.

It seems to be different than #837

Thank you.

@commonsensesoftware
Copy link
Collaborator

Interesting. I'll have a look. The strange thing is the current source doesn't show anything on line 198. The repro will definitely help. Thanks

@icnocop
Copy link
Author

icnocop commented Aug 3, 2022

This is in the dev/css/preview3-fixes branch so this is line 198:

@commonsensesoftware
Copy link
Collaborator

Doh!

Hmm... looks like apiVersion is somehow coming up null. That shouldn't happen. Defending against null is easy, but I suspect there is a little more to the issue.

@icnocop
Copy link
Author

icnocop commented Aug 3, 2022

I'm thinking my example code is missing a call to what was previously MapVersionedODataRoute, but I'm not sure that method is available for a web application targeting .net core 3.1 in the latest code for an OData API.

@commonsensesoftware
Copy link
Collaborator

I found the root cause. It's here:

This is an over-optimization. OData adds some additional endpoints based on convention, but doesn't copy the existing metadata from any other endpoints. This is problematic when there are multiple EDMs, but also if API Versioning never got a chance to visit the endpoint. As a result, you can end up with a versioned endpoint that doesn't have the API Versioning metadata attached.

The first clue is skipping over the null check and watching it filter out endpoints successfully. The following should have been listed:

  • api/People
  • api/People/$count

But the $count endpoint is dynamically added by convention without any metadata. Handling the null keeps it from blowing up, but it's still wrong. The endpoints need to be fixed up regardless of whether there is more than one EDM.

You might also notice 3 endpoints in your repro, but that's because there is a mismatch in the route templates (and a different problem). There should only be 2.

The fix will go into the next release. Thanks for putting together the repo. It helped track down the issue.

@commonsensesoftware
Copy link
Collaborator

6.0 has been officially released and contains this fix. Thanks for taking the time to report it and help narrow down the culprit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants