InvalidSpecification raised for OperationId
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- openapi, python
- Domain
- api, backend-api-design
Research direction
Reproduce the regression with the conflicting paths in openapi.yaml and inspect the duplicate OperationId validation introduced while resolving issue #96. Compare the behavior in version 0.3.0 with the controller-qualified operation IDs described here. Done means the intended uniqueness behavior is established and the breaking-change or compatibility behavior is covered and documented.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- Python
- Stars
- 409
- Forks
- 73
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from python-openapi/openapi-spec-validator
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 30/100
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
python-openapi/openapi-spec-validator#400 · 1 comment ·
-
kind/bug/confirmed
Difficulty 5/5 Over a week Newbie friendliness 25/100
python-openapi/openapi-spec-validator#373 · 1 comment ·
All issues in python-openapi/openapi-spec-validator
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
canonical/paas-charm#368 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
tech debt
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
StevenBlack/hosts#3256 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
qualcomm/qai-appbuilder#275 ·