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

Misleading error for linked schema properties #413

Closed
michelecurioni opened this issue Apr 7, 2022 · 2 comments
Closed

Misleading error for linked schema properties #413

michelecurioni opened this issue Apr 7, 2022 · 2 comments

Comments

@michelecurioni
Copy link

Hi,
I have an openapi definition where some schema entities reference other entities. The validation detects a casing error (I'm using a camel casing rule) on the linked object, but the error reports the problem on the main object.

For instance, the Application entity should fail validation because the "_links" property is not camel case:

components:
  schemas:
    Application:
      type: object
      properties:
        applicationId:
          type: string
          description: The application id generated when the application is created
          example: 48dba7ed-8eb5-468a-9067-2f3f8e70458b
        _links:
          type: object
          properties:
            self:
              $ref: '#/components/schemas/Link'
    ApplicationResponse:
      properties:
        application:
          $ref: '#/components/schemas/Application'
    Link:
      type: object
      properties:
        href:
          type: string

but the error is reported against ApplicationResponse entity:

errors
  Message :   Property names must be camel case
  Rule    :   property-case-convention
  Path    :   components.schemas.ApplicationResponse.properties.application
  Line    :   57
@dpopp07
Copy link
Member

dpopp07 commented Apr 7, 2022

Hi @michelecurioni. Unfortunately, this is a known issue with Spectral that we haven't been able to get any traction on. We perform our validations on the resolved specification and rely on Spectral to map the paths back to the original document. In many cases, this works well, but there are also many cases where this breaks.

We've opened two issues (here and here) against their project with much more detail if you'd like to check them out and perhaps advocate for Spectral addressing them. We've done some work to try and work on a solution within their codebase but haven't had the bandwidth to continue that lately.

@dpopp07
Copy link
Member

dpopp07 commented Aug 5, 2022

@michelecurioni this has been resolved in v0.83.1 of this tool

@dpopp07 dpopp07 closed this as completed Aug 5, 2022
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