InvalidSpecification raised for OperationId
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- openapi, python
- Área
- api, backend-api-design
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- Python
- Estrellas
- 409
- Forks
- 73
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de python-openapi/openapi-spec-validator
-
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 30/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
python-openapi/openapi-spec-validator#400 · 1 comentario ·
-
kind/bug/confirmed
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
python-openapi/openapi-spec-validator#373 · 1 comentario ·
Todos los issues de python-openapi/openapi-spec-validator
Issues similares
-
documentation help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
simonw/sqlite-utils#872 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100