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

Invalid JSON + invalid OAS is not recognized as such #2641

Open
bereg2k opened this issue Jun 13, 2024 Discussed in #2630 · 4 comments
Open

Invalid JSON + invalid OAS is not recognized as such #2641

bereg2k opened this issue Jun 13, 2024 Discussed in #2630 · 4 comments
Assignees
Labels
enhancement New feature or request s/needs-info validation Regarding the validation functionality

Comments

@bereg2k
Copy link

bereg2k commented Jun 13, 2024

Discussed in #2630

Originally posted by bereg2k June 2, 2024
Hello!

I have an invalid JSON which is invalid OAS too, but linting it doesn't report any errors:

invalid_spec.json

{
  "openap": "3.0.3",
  "info": {
    "title": "",
    "version": ""
  },
}
  • there's trailing , without any other members (invalid JSON)
  • "openap" instead of "openapi" (invalid OAS)
  • no "paths" (invalid OAS).

My ruleset is...

.spectral.yaml

extends: [[spectral:oas, all]]

The output is:

% spectral lint path/to/file/invalid_spec.json  -v -D    

Found 52 rules (52 enabled)
Linting /path/to/file/invalid_spec.json
No results with a severity of 'error' found!

What am I doing wrong here?

@daniel-white
Copy link

just a few thoughts

  1. the trailing comma problem isn't really the domain of spectral - spectral cares more about the sematics of the content than the syntax. another tool might help!
  2. im thinking like a "format/detect/core property" configuration for rule sets that the core engine would consult to ensure that one of those must exist: json schema, oas, asyncapi, etc. it might have to be behind a new flag but if the "detector" doesn't find one, then its an error
  3. since the ruleset didn't see this as an oas file, then it didnt run, hence missing paths wasn't checked

@bereg2k
Copy link
Author

bereg2k commented Jun 24, 2024

@daniel-white Thanks for your response!

  1. Can you please recommend me something appropriate for the syntax validations though?
  2. Should I create a separate issue for it? ("openap" key issue)
  3. But shouldn't the tool see all the files I am trying to validate as OAS files explicitly, and throw errors accordingly? The file could be incorrect due to human error, and internally Spectral "decides" that it's not OAS and so won't do any validation... That's kinda weird (if I understood this correctly).

@mheguy
Copy link

mheguy commented Jul 19, 2024

internally Spectral "decides" that it's not OAS

It's just code.
If there is an "openapi" key in the root then it applies oas rules.

As Daniel mentioned, the tool should probably say something if it doesn't match on oas, aas, or json schema. Outside of that, there's not much to do.

@ponelat
Copy link

ponelat commented Aug 16, 2024

@mnaumanali94 do we have any use-cases for "passing through unknown spec files as error free"? I would consider throwing an error if spectral can't identify the specification?

Couple of ways we can improve this:

  • Set a flag, so that the user can force which specification to look at.
  • Set a flag, for forcing the data type (JSON or YAML).
  • Fail if spectral cannot identify specification.

@ponelat ponelat added enhancement New feature or request validation Regarding the validation functionality s/needs-info labels Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request s/needs-info validation Regarding the validation functionality
Projects
None yet
Development

No branches or pull requests

5 participants