stoplightio / spectral

A flexible JSON/YAML linter for creating automated style guides, with baked in support for OpenAPI (v3.1, v3.0, and v2.0), Arazzo v1.0, as well as AsyncAPI v2.x.
https://stoplight.io/spectral
Apache License 2.0
2.46k stars 233 forks source link

oas3-valid-schema-example: Issue with properties called "default"? #1972

Open m-mohr opened 2 years ago

m-mohr commented 2 years ago

Describe the bug

oas3-valid-schema-example: I have an OpenAPI file with an example that contains a property default. It seems that's the reason validation somehow applies strange rules for it.

I'm getting two errors:

1713:28 error oas3-valid-schema-example schema is invalid: data/type must be equal to one of the allowed values, data/type must be array, data/type must match a schema in anyOf paths./udf_runtimes.get.responses[200].content.application/json.example.PHP.default 1726:28 error oas3-valid-schema-example schema is invalid: data/type must be equal to one of the allowed values, data/type must be array, data/type must match a schema in anyOf paths./udf_runtimes.get.responses[200].content.application/json.example.R.default

I don't fully understand why that is. The default schema specifies it should be "string" and the values in the examples are strings.

To Reproduce

  1. Given this OpenAPI/AsyncAPI document: https://github.com/Open-EO/openeo-api/blob/spectral6/openapi.yaml
  2. and the config file: https://github.com/Open-EO/openeo-api/blob/spectral6/.spectral.yml (this doesn't give an error, you need to remove the "except" rules first)
  3. Run this CLI command: spectral lint openapi.yaml
  4. See the error given above

Expected behavior No error message, but instead a successful validation. This worked before in 5.x, but got broken once I migrated from 5 to 6.1.

Environment (remove any that are not applicable):

j616 commented 2 years ago

Hello. Has any progress been made on this? It seems the same issue presents for the keyword type. Unfortunately, in our case, we can't disable the error on specific resources as we split our schemas & examples out into separate files. I believe overriding of rules is only supported in the top level document.

meem commented 2 years ago

We're also encountering this issue in spades with our API definition. Any outlook on getting this fixed?

mtjandra commented 6 months ago

I am running into this issue as well. Using version 6.10.1

As a workaround, I am disabling rule oas3-valid-schema-example for the schema which has an example containing a property with the name default.