InvalidSpecification raised for OperationId
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- openapi, python
- Bereich
- api, backend-api-design
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- Python
- Sterne
- 409
- Forks
- 73
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus python-openapi/openapi-spec-validator
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 30/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 42/100
python-openapi/openapi-spec-validator#400 · 1 Kommentar ·
-
kind/bug/confirmed
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
python-openapi/openapi-spec-validator#373 · 1 Kommentar ·
Alle Issues in python-openapi/openapi-spec-validator
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
syfoud/Simulated_Scepter#172 ·
-
A cancelled tests run makes the coverage comment workflow fail and reports it as a red check on main Offenarea: ci bug perceived difficulty: 3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Nitjsefnie-Harness-Commons/daedalus#921 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
EleutherAI/lm-evaluation-harness#4207 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 92/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
ClickHouse/clickhouse-connect#1057 ·