Follow-up for 653 Issue - Duplicate operationIds and underscore symbol - AutoRest has a bug around underscores

The issue #653 mentions an article about how to solve the problem with duplicate operationIds generated by Swashbuckle.

Duplicate operationId is not only Swashbuckle fault, Autorest can’t parse OperationId with more than one underscore correctly: so if your operationIds are :

"operationId": "Debug_Get",
"operationId": "Debug_GetByid",
"operationId": "Debug_ReceiveCommandByjsonData",
"operationId": "Debug_Get2Bymodel",

Autorest will work fine.

if you have some prefixed operationIds like (they are still unique though):

"operationId": "V1_Debug_Get",
"operationId": "V1_Debug_GetByid",
"operationId": "V1_Debug_ReceiveCommandByjsonData",
"operationId": "V1_Debug_Get2Bymodel",

Autorest fails to interpert these operationIds correctly - you’ll get a message

error: [FATAL] Error generating client model: Found operation objects with duplicate operationId ‘V1_Debug’. OperationId must be unique among all operations described in the API.

It was mentioned by @VR-Architect in #651 that it was fixed in v.0.14, but I checked valid swagger.json with both v.0.15 and v.0.14 and they are both failing to parse operationid when it has more than one underscore.

As soon as I update swagger definition to have operationId with just one underscore - it works fine.

It seems like an issue in AutoRest operationId parsing.

[mossyblog]

If you need a case study for why verb_another_verb_whatever etc is going to continue then look no further than EVE Online - https://esi.tech.ccp.is/latest/swagger.json?datasource=tranquility

Point is if you’re going to walk into this entire “AutoRest” with the attitude of “if its not within our bubble, its not at all” then you’ve learned nothing from our days with SOAP.

Deferring for “stable” is also a weak avoidance behaviour. Address the issue and keep this open until you’ve confined the solution to a reasonable approach. GitHub isn’t Microsoft Connect and the days of when we used to triage problematic issues like this with “as per design” or “deferred to x” isn’t going to work with OSS space.

This is how you bank hate debt with developers.

[fearthecowboy]

I have never been a fan of the implicit decision in AutoRest to parse the operationId and use that as the basis for choosing “method-group” and “method” names. Seems kinda hacky to me to begin with.

AutoRest is replete with implicit assumptions … such is the life when you inherit a codebase.

Later this week, we’re starting work on an overhauled configuration system that will make it simpler to override behavior in the code generation process (by providing an external file that contains the information to the generator), without having to edit the swagger file itself (which helps not only @bowman-jm 's scenario of an automated swagger generation, but others who don’t want to pollute the swagger with information that doesn’t really describe the wire-behavior)

It should not be terribly difficult to provide an override for methodgroup and method name on a per-operation basis in there.