Wrong operationid generated

Hello, This bug is probably the same as bug 96. OperationID continues to be generated with a suffix, even when there’s no other method with the same operationid in the same class.

This issue is easy to reproduce:

1. Create two controllers classes.
2. Create one method with the same name in both classes.
3. http://yoursite/v3/api-docs will produce one operationid correct and the other will have the 1 suffix.

Ex: MyFirstClass.java:

    @Operation(operationId = "save")
    @PostMapping(path = "/")
    @ApiResponse(responseCode = "200", description = "Success")
    public ResponseEntity save(@RequestBody String request) {
      return null;
    }

MySecondClass.java:

    @Operation(operationId = "save")
    @PostMapping(path = "/")
    @ApiResponse(responseCode = "200", description = "Success")
    public ResponseEntity save(@RequestBody String request) {
      return null;
    }

After generation, one method will have the correct operationid (save), but the other one will have a wrong operationid(save_1) This bug is happening with SpringDoc 1.3.0, SpringBoot 2.2.6, openJDK 11 64bits on Windows.

[jdbranham]

Nvm - I just realized there is an OperationCustomizer class while browsing the source code -

https://github.com/springdoc/springdoc-openapi/blob/2da39aae2976ef1cc888e5696caf763fb6f05fcf/springdoc-openapi-common/src/main/java/org/springdoc/api/AbstractOpenApiResource.java#L641

I was able to provide a bean and customize my generated names =]

Thanks for a great project!!

@Bean
public OperationCustomizer operationIdCustomizer() {
  OperationCustomizer c = new OperationCustomizer() {
    @Override
    public Operation customize(Operation operation, HandlerMethod handlerMethod) {
	Class<?> superClazz = handlerMethod.getBeanType().getSuperclass();
	if (Objects.nonNull(superClazz) && superClazz.isAssignableFrom(CrudController.class)) {
		String beanName = handlerMethod.getBeanType().getSimpleName();
		operation.setOperationId(String.format("%s_%s", beanName, handlerMethod.getMethod().getName()));
	}
	return operation;
    }
  };
  return c;
}

[tezine]

Hi @tezine,

This is not a bug, but a normal behaviour as we don’t want to generate incorrect spec:

• The operationId should be unique
• When it not the case (for example in case of polymorphism), springdoc generates a unique id

If you have two operations with the same id, your spec will be incorrect.

Please make sure you use the last stable version: v1.3.9 indeed.

Thank you @bnasslahsen for the quick response. It just think it doesn’t make any sense. For instance, I’m generating REST calls to Angular in typescript. In this situation, I have two calls:

MyFirstClassService.save() and MySecondClassService.save_1(). //It doesn't make sense.