Parameters with the same name but different types are valid.

[mohsen1]

This specs is valid:

---
swagger: '2.0'
info:
  version: 0.0.0
  title: Simple API
paths:
  /{email}:
    parameters:
      - name: email
        in: path
        type: string
    get:
      parameters:
        - name: email
          in: query
          type: string
      responses:
        200:
          description: OK

From https://github.com/swagger-api/swagger-ui/issues/828#issuecomment-83150803

[whitlockjc]

I assume it's being flagged as not valid? I agree it should be valid although I wonder how we'll handle this on the middleware side of things. req.swagger.params can only have one email entry.

[whitlockjc]

Again, I'd love to hear from @webron. I do think technically this is valid but from a tooling perspective, it would not be easy to support.

[webron]

Unfortunately, for 2.0, this is valid.

[whitlockjc]

I can work with it. I'll likely do a first come, first served approach and print warnings as there is no way I'm sure to handle this that doesn't end up with a crappy user experience.

[mortias]

In which case is this validation error correct?

[whitlockjc]

I never said the validation error was correct, that's why this bug is still open. :)

[whitlockjc]

But as I said above, from a tooling perspective things are a little more tricky. Right now, we use req.swagger.params.{paramName} to get access to a parameter's schema, raw value and processed value. If you have two different parameters with the same name, this no longer works. That's why this issue is still open is because it should be valid but the fix for this is not simply just turning off the validation as it changes the interface.

[nikhiljindal]

@whitlockjc Thanks for explaining the problem. I dont know much about the code, but how about using req.swagger.params.{paramName+paramType} instead of req.swagger.params.{paramName}? How big a change will that be?

[whitlockjc]

For 1.0.0, that's likely what will happen.

[nikhiljindal]

@whitlockjc Whats the timeline for 1.0.0?

[whitlockjc]

Not sure, this project isn't getting the same attention these days due to my involvement in other things. I'd love any help I can get but this project is by no means dead...just a little slower than it use to be.

[theigl]

I just ran into this as well. For backwards-compatibility I'm accepting the same parameter as query or as form parameter. Is there a fix and/or workaround for this at the moment?

[whitlockjc]

I don't see me fixing this in swagger-tools. This would be a huge rewrite of everything and we're already in the process of splitting swagger-tools into smaller, specific projects (#335). Sway already supports this but the middleware isn't completed yet.

[sido420]

Any updates on this? i have a large codebase where swagger tools never complained about this and all of a sudden it started throwing errors.

Is there a workaround or any tips to avoid this issue?

[sido420]

I'm not getting any errors in 0.10.1. However, 0.10.2/3 throw following errors. However, I dont have any name conflicts.

#/paths/~1list/put/parameters/1/name: Parameter already defined: undefined
#/paths/~1list/put/parameters/2/name: Parameter already defined: undefined
#/paths/~1list/post/parameters/1/name: Parameter already defined: undefined

[whitlockjc]

The error message is suspect, as in undefined, shouldn't be there. Do you have a reproduction recipe?