InvalidSpecification raised for OperationId

Ouverte
#114 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
openapi, python
Domaine
api, backend-api-design

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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
Langage dominant
Python
Étoiles
409
Forks
73
Aucune PR mergée en 30 j

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de python-openapi/openapi-spec-validator

Toutes les issues de python-openapi/openapi-spec-validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.