A controller with
public async Task<ActionResult<Something>> GetSomethingAsync([Required] Guid foo)
becomes
System.Threading.Tasks.Task<Something> GetSomethingAsyncAsync(System.Guid foo);
For the generated code I'd also simply prefer GetSomethingAsync.
I usually use operationId without Async suffix. Then I do not have this problem. In my opinion operationIds should have names tailored for the clients (and clients are not interested in some async implementation details)
That way you are forcing me to use OperationIds. Maybe there is no benefit for me in using them or I do want to reflect as much as I can to my clients without constantly adapting OperationIds.
operationId has the benefit, that internal implementation details (name of controller method) is not faced to clients. xxxAsync suffix is for me technical restriction/pattern and API (operationIds) is business/client point of view. Separating the technical part from the client part seems being plausible. Of course it is some overhead for improved quality - depends on your scenario how much you want to invest into that.
NSwag generates operation ids in the form controllerName_operationName where operationName is stripped off the Async suffix. Async should not be part of a spec as it is an implementation detail. How did you generate the spec? Can you post process it?
Sorry guys, this was my bad. (If I remember correctly) I already had an OperationId in place which had the Async suffix in its name and the generation additionally added an Async suffix.
Please close if you're fine with this behavior (I am).
I think Async should not be in the operation id as it is an implementation of the used language (leaky abstraction), ie all operations are async and this its not needed
Is it possible to make Adding Async at the end of a method as Settings option ?
@baskialdensys please open a new issue for that