Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ValueError when two operations have the same tag and similar operation IDs. #129

Closed
MartinDelVecchio opened this issue Jul 13, 2017 · 4 comments
Milestone

Comments

@MartinDelVecchio
Copy link

MartinDelVecchio commented Jul 13, 2017

When my swagger has two paths with the same tag, and similar operation IDs, pyswagger raises a ValueError when I try to execute one of them.

Here is a swagger.json, which is the standard pet store example, expanded to demonstrate this problem:

   swagger: "2.0"

   info: 
    version: "1.0.0"
    title: "Swagger Petstore"
    description: "A sample API that uses a petstore as an example to demonstrate features in the swagger-2.0 specification"
    termsOfService: "http://swagger.io/terms/"
    contact: 
      name: "Swagger API Team"
    license: 
      name: "MIT"

   host: "petstore.swagger.io"

   basePath: "/api"

   schemes: 
    - "http"

   consumes: 
    - "application/json"

   produces: 
    - "application/json"

   paths: 

    /pets: 
      get: 
        description: "Returns all pets from the system that the user has access to"
        operationId: get
        tags:
        - Albany
        produces: 
          - "application/json"
        responses: 
          "200":
            description: "A list of pets."
            schema: 
              type: "array"
              items: 
                $ref: "#/definitions/Pet"

    /hobbies: 
      get: 
        description: "Returns all hobbies from the system that the user has access to"
        operationId: hobbies-get
        tags:
        - Utica
        produces: 
          - "application/json"
        responses: 
          "200":
             description: "A list of hobbies."
            schema: 
              type: "array"
              items: 
                $ref: "#/definitions/Pet"
                         
   definitions: 
    Pet: 
      type: "object"
      required: 
        - "id"
        - "name"
      properties: 
        id: 
          type: "integer"
          format: "int64"
        name: 
          type: "string"
        tag: 
          type: "string"

Here is what happens when I try to execute the first operation, 'get':

>>> import pyswagger
>>> app = pyswagger.App._create_ ('swagger.json')
>>> app.op['get']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/pyswagger/utils.py", line 81, in __getitem__
    raise ValueError('Multiple occurrence of key: {0}: {1}'.format(k, ret))
ValueError: Multiple occurrence of key: get

Some debugging reveals the duplicate keys to be : 'Albany!##!get' and 'Utica!##!hobbies-get'.

These are not duplicate keys, just similar keys. And the tags are totally different. In fact, it doesn't matter what the tags are; as long as both paths have any tag, this exception is raised.

According to the Swagger spec, the operationId is:

Unique string used to identify the operation. The id MUST be unique among all operations described in the API. Tools and libraries MAY use the operationId to uniquely identify an operation, therefore, it is recommended to follow common programming naming conventions.

My reading of this is that an operation ID is all that is necessary to identify an operation, and thus I can't figure out why this exception is being raised.

Can you explain why two similar but unique operation IDs are resulting in this duplicate-key exception?

And is there a way to work around it?

Thanks.

@mission-liao
Copy link
Member

This part is done in pyswagger.utils.ScopeDict, to workaround it:

You need to pass both tag(the first tag in tags) and operationId when using it, ex:

app.op['Utica', 'hobbies-get']
app.op['Albany', 'get']

And maybe I can still fix your use case, let me investigate it this weekend.

@mission-liao mission-liao added this to the v0.8.32 milestone Jul 14, 2017
@MartinDelVecchio
Copy link
Author

The workaround works.

Please let me know when you have fixed the problem.

Thanks!

@mission-liao
Copy link
Member

The fix is released in v0.8.32 and your use case is added to test case.

@MartinDelVecchio
Copy link
Author

I upgraded to v0.8.32, removed my primitive hack, and re-tested. It works.

Thank you for your quick attention to this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants