OData Swagger sample broken on 5.0.0 rc1

[spaasis]

Hi,
I just cloned the newest version and started the Core Swagger OData sample.

Repro:

1. Select version definition v3
2. Click on "Acme GET /api/Acme"

Expected behavior:
Only the selected definition expands in the UI

Actual behavior:
Every Acme definition expands.

I've crossed paths with this before, but can't really guess what is the problem. The behaviour is present in 5.0.0 rc1.

Probably related: swagger-api/swagger-ui#5032

[commonsensesoftware]

Thanks for reporting this. This is definitely strange behavior. Here's some things I've discovered:

• The operationId is optional in the Open API specification (see here)
• Swashbuckle is using AttributeInfo.Name for the operationId, which may be null (see here)
• According to the documentation AttributeRouteInfo.Name is the name of the associated route

Under most attribute routing scenarios, the name would probably be null. For example: [Route("api/acme")]. The name is meant to come from [Route("api/acme", Name = "GetByName")], which would have to be unique. OData still relies on registration of a route, even with Endpoint Routing (although it doesn't seem to do anything). This name is paired with the registration of MapODataServiceRoute. In the strictest of sense, the right thing is being done on both sides, but they are incongruent.

I need to think about how this should work. OData 8.0 is almost upon us and I'm coordinating with the team. Depending on the release will depend on whether I promote this to official or defer. There's going to be more changes. Marking this release RC may have been premature (with respect to supporting 8.0).

The simplest solution is to add a custom operationId generator which does nothing (e.g. returns null). This will get you the behavior you want in the interim (I verified it). For example:

services.AddSwaggerGen( options => options.CustomOperationIds( api => null ) );

I hope that helps - for now.

[spaasis]

Alright, brilliant! Thanks (again) for the quick workaround. Good luck fixing it for good 👍

[commonsensesoftware]

I'll be swapping out the use of the AttributeRouteInfo.Name with an OData-specific property instead. It will have the same internal behavior, but will prevent this from being an issue that you have to mitigate like this. Look for the change in RC 2. Thanks for trying out the RC.