The resolution for issue #96 (duplicated OperationID not detected) introduced a breaking-change or regression. Upon updating dependencies to version 0.3.0, the connexion library now reports this error when I run my longstanding openapi.yaml:
connexion.exceptions.InvalidSpecification: Operation ID 'find' for 'get' in '/apikey' is not unique
Each of my path prefixes refers to a different x-openapi-router-controller class; because they share similar logic, I use the same operationId function name for methods like get/find/delete for each of the controllers.
Shouldn't the duplicate detection logic look for a uniqueness across both x-openapi-router-controller and operationId? If my openapi.yaml file needs updating (due to a change in the standard, or my misunderstanding of the standard), then this breaking-change needs to be called out clearly in changelog / release notes.
I'd like it to handle this use-case; for now I'll adjust openapi.yaml to handle this new behavior in 0.3.0 but this could be a huge headache for other users. Perhaps you should add a compatibility flag for such users to transition between now and the next release.
Below is an example of conflicting paths:
/apikey:
get:
summary: Find APIkeys by conditions
operationId: find
parameters:
- description: APIkey ID
...
responses:
200:
...
x-openapi-router-controller: controllers.apikey.APIkeyController
/message:
get:
summary: Find messages by conditions
operationId: find
parameters:
- description: Message ID
...
responses:
200:
...
x-openapi-router-controller: controllers.message.MessageController
The resolution for issue #96 (duplicated OperationID not detected) introduced a breaking-change or regression. Upon updating dependencies to version 0.3.0, the connexion library now reports this error when I run my longstanding openapi.yaml:
Each of my path prefixes refers to a different x-openapi-router-controller class; because they share similar logic, I use the same operationId function name for methods like get/find/delete for each of the controllers.
Shouldn't the duplicate detection logic look for a uniqueness across both x-openapi-router-controller and operationId? If my openapi.yaml file needs updating (due to a change in the standard, or my misunderstanding of the standard), then this breaking-change needs to be called out clearly in changelog / release notes.
I'd like it to handle this use-case; for now I'll adjust openapi.yaml to handle this new behavior in 0.3.0 but this could be a huge headache for other users. Perhaps you should add a compatibility flag for such users to transition between now and the next release.
Below is an example of conflicting paths: