[OpenAPI] NullReferenceException with route parameters provided by inherited controller
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 281
Description
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Describe the bug
Controllers can provide route parameters through the `RouteAttribute`. Actions in controllers that inherit from that base controller may optionally use that route parameter. OpenAPI document generation fails with a `NullReferenceException` trying to access the `ModelMetadata` from the `ParameterDescriptions`.
This issue is also reproducible if a route parameter is specified in the controller's `RouteAttribute`, it does not need to be from an inherited controller.
### Expected Behavior
I'm not sure what the expected behaviour is for OpenAPI, but the document generation should not be failing with an exception.
### Steps To Reproduce
https://github.com/anarian/dotnet-openapi-nullbug
1. Debug the application
2. Exception will be thrown immediately
### Exceptions (if any)
```
System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=WebApplication1
StackTrace:
at Microsoft.AspNetCore.OpenApi.Generated.F340FEECD1E82BE934851862FC854B212C14780C957B4A4FC4BB1EED9CE15554D__XmlCommentOperationTransformer.TransformAsync(OpenApiOperation operation, OpenApiOperationTransformerContext context, CancellationToken cancellationToken) in D:\source\WebApplication1\WebApplication1\obj\Debug\net10.0\Microsoft.AspNetCore.OpenApi.SourceGenerators\Microsoft.AspNetCore.OpenApi.SourceGenerators.XmlCommentGenerator\OpenApiXmlCommentSupport.generated.cs:line 428
```
### .NET Version
10.0.100-rc.2.25502.107
### Anything else?
We're currently using a pattern where we have multiple user types that have a specific ID in the route. Each user type has an abstract controller that provides initial validation for the user's access before the controller action is called. The inherited controllers all implement the same interface which is how ensure the same actions for the different user types at compile-time for the controllers. I considered adding the route parameters to the actions even if they aren't used, but because the user ID argument names have different names and maybe different types, I was unable to work around this issue.
Contributor guide
Assessment
This issue has not been assessed yet.