illogical oneOf detection missing about redocly-cli HOT 8 OPEN

no-illogical-schemas could be a potential name for the rule.

We could also check allOf for illogical behavior:

https://json-schema.org/understanding-json-schema/reference/combining#illogicalschemas

from redocly-cli.

Thanks for reporting! This looks more like an enhancement though.

from redocly-cli.

@adamaltman a question based on the next example from the link you provided:

{
  "oneOf": [
    { "type": "number", "multipleOf": 5 },
    { "type": "number", "multipleOf": 3 }
  ]
}

Wouldn't it be also considered an illogical use of oneOf? The number 15 will be technically valid against both of the subschemas. Is there a way to distinguish an intentional use of oneOf to exclude certain numbers from an example of illogical use?

from redocly-cli.

It is indeed illogical too.

If possible values intersect, they are illogical in the context of oneOf.

I don't know what you mean by the intentional use of oneOf to exclude certain numbers? oneOf would not be the appropriate tool to exclude certain numbers. Instead, more detailed schema criteria should be used.

I suspect there is a good amount of the nullable case in the real world (at least for people who adopted 3.1 with nullable). I'm not sure if there are many of this multiple of 3 and 5 type cases in the real world. And I suspect if there is, it would mostly be something like greater or equal to 0 and also something else that includes 0 where 0 is the culprit and could match two schemas.

from redocly-cli.

I don't know what you mean by the intentional use of oneOf to exclude certain numbers?

The same example - all multiples of 3 and 5 will be valid against that oneOf except for multiples of 3 AND 5 at the same time. (e.g. 3, 5 - valid, 15 - invalid). So technically a similar trick could be used intentionally.

I'm not sure if there are many of this multiple of 3 and 5 type cases in the real world

Most likely not too much. And the vast majority should be using anyOf instead. But how about the following:

oneOf:
- type: object
  properties: 
    foo: { type: string }
- type: object
  properties:
    bar: { type: number }

Technically any object is invalid against this schema since additionalProperties are true by default and any field will be valid against both schemas. However, I suppose it's pretty common to write schemas like that. Do we want to error on such cases as well?

from redocly-cli.

@tatomyr I think the schema is written incorrectly for "I want 15 to be invalid" and the user would need to compose of more complex objects with not multiple of 15. So, I do believe it is still illogical. I'm not sure we need to check for all aspects of illogicality.

Your example with additionalProperties is a common illogical situation. I believe that I would want to know it is illogical, but there are likely people who would like to assume additionalProperties was false even though it isn't false.

I think the rule should take into consideration required properties. Sometimes a missing required property can make the case logical even without additionalProperties set to false.

from redocly-cli.

Makes sense. Thanks for the explanation!

from redocly-cli.

This is a big black hole of linting rules. It would be amazing!! Certainly, there are a million configurable rules you can create for these types of checks, similar to #1318

There has never really existed a good JSON Schema linter, which is something the JSON Schema core group has discussed many times, but without the budget to produce something. I would definitely consider discussing at least some of the bigger schema authoring mistakes they encounter to try and build some rules around them.

from redocly-cli.