path is defined multiple times

Describe the bug After updating from 5.3.0 to 5.4.0 I got the following error message:

5671:15 error path-params Path parameter path is defined multiple times. Path parameters must be unique.

I looked through the file and there’s only a single mention of a path parameter

To Reproduce

Here’s the OpenAPI file I’m working on: https://github.com/Open-EO/openeo-api/blob/bc79b312768cc462a99f09d1f9c8caeb47b5dfbc/openapi.yaml I’m running: spectral lint openapi.yaml Ruleset is spectral:oas

Expected behavior No error message.

Environment (remove any that are not applicable):

• Library version: 5.4.0
• OS: Windows 10 + Linux on TravisCI

Additional context Downgrading to 5.3.0 doesn’t show an error.

[nulltoken]

@m-mohr After a quick look at the code, I reversed engineered the problem. From the put and delete operation standpoint, the issue is legit. The parameter is indeed defined at the operation level, but also exists at the path parameters level.

 '/files/{path}':
    parameters:
      - $ref: '#/components/parameters/file_path'    # <- defined here at the top level
    get:
      [...]
    put:
      summary: Upload a file to the workspace
      operationId: upload-file
      description: >-
        This service uploads a new or updates an existing file at a given path.


        Folders are created once required by a file upload. Empty folders can't
        be created.
      tags:
        - File Storage
      security:
        - Bearer: []
      parameters:
        - $ref: '#/components/parameters/file_path'  # <- and also here at the operation level
      [...]
    delete:
      summary: Delete a file from the workspace
      operationId: delete-file
      description: >-
        This service deletes an existing user-uploaded file specified by its
        path. Resulting empty folders MUST be deleted automatically.


        Back-ends MAY support deleting folders including its files and
        sub-folders. If not supported by the back-end a
        `FileOperationUnsupported` error MUST be sent as response.
      tags:
        - File Storage
      security:
        - Bearer: []
      parameters:
        - $ref: '#/components/parameters/file_path'  # <- and also here at the operation level
      [...]

Now, I can see that there are at least two things that seem wrong from the UX perspective:

• reported path is ["components", "parameters", "file_path"]. This is very unhelpful to actually understand the context of the problem (and reminds me a lot of of https://github.com/stoplightio/spectral/issues/1254#issuecomment-650575599)
• the error message isn’t very helpful and should be enhanced. Maybe provide a hint to the user with regards to what he/she look for, and where, in the document to fix the issue.

@P0lip @philsturgeon Improving the error message should be quite easy in this context. However, I’m slightly more concerned about the “misleading” path. Thoughts?

[nulltoken]

But pointing to [“components”, “parameters”, “file_path”] is obviously completely misleading. Why does it actually point to the components?

@m-mohr Yep. That was what I was pointing at with my previous comment:

If it had put the path: [“paths”, “/files/{path}”, “parameters”] or any of the paths in the operations, I guess I could have found the issue.

Thanks to your issue and #1254, we’ve now got two great cases to improve the report of paths so that they’re more helpful.