Btw original implementation already did that, so it added indexes only if there was any duplicate. This is seen from Unit tests.
Also it was done in a way that only autogenerated operationids were deduplicated and not operation ids that were defined by the user.

The only breaking change was, that method name was attached at the end everytime. But this could be easily fixed :)

Btw original implementation already did that, so it added indexes only if there was any duplicate. This is seen from Unit tests.

No completely true, the original implementation also modified the first duplicate operationId adding a 1. In this implementation the first operationId is not modified and the second one is modified with _1. See https://github.com/micronaut-projects/micronaut-openapi/pull/542/files#diff-bc02d3ee7e696a0c68e33b82db5b9f9cabf443c78c771b1509650f086a21de4aL80-L81

This PR will be included in 2.6.1 release that will target Micronaut 2.5.x

No completely true, the original implementation also modified the first duplicate operationId adding a 1

I agree. But in that case there is no big difference. Because you cannot know what operation id was first if you don't track history.

For example you have:

class B {
    index()
} 

And then in next release you add:

class A {
    index()
} 

It's not possible to know what method was original with name index, so you might break user expected "operation id" value anyway. Maybe Micronaut could create even more unique operation ids, or just copy Spring behavior that will please most people :)

But good think you fixed that, so it does not break user experience, thank you! My bad that I added breaking behavior

I've copied Spring behavior for this with the suffix _1, _2,...

Don't need to apologies, I should have spent more time in the first place reviewing the original PR. Thanks for your contribution :)