-
Notifications
You must be signed in to change notification settings - Fork 138
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
illogical oneOf detection missing #1486
Comments
We could also check https://json-schema.org/understanding-json-schema/reference/combining#illogicalschemas |
Thanks for reporting! This looks more like an enhancement though. |
@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 |
It is indeed illogical too. If possible values intersect, they are illogical in the context of I don't know what you mean by the intentional use of 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. |
The same example - all multiples of 3 and 5 will be valid against that
Most likely not too much. And the vast majority should be using oneOf:
- type: object
properties:
foo: { type: string }
- type: object
properties:
bar: { type: number } Technically any object is invalid against this schema since |
@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 Your example with I think the rule should take into consideration required properties. Sometimes a missing required property can make the case logical even without |
Makes sense. Thanks for the explanation! |
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. |
Describe the bug
I found an impossible
oneOf
definition.I'm constantly trying to educate people about
oneOf
vsanyOf
. In any case, it would be better if the lint tool could catch impossible definitions.To Reproduce
Most simple reproduction:
Here is the actual place I spotted it:
$ref
to InvoiceTimeShift object,null
.object
ornull
.Given that Rebilly is likely to change that before we finish this, here is how to reproduce it.
Excerpt from a schema:
Now, let's look at
InvoiceTimeShift.yaml
(only the first couple of lines needed):Why is this impossible?
oneOf
needs to match one and only only option. In this case,InvoiceTimeShift
can benull
, and the second option is also null (both the same). There is no way to distinguish which one was intended. Therefore, this is an impossibleoneOf
.Expected behavior
I expected to be alerted to an incorrect
oneOf
definition.oneOf
requires each item must be able to be distinguished from the other items (as opposed toanyOf
).Logs
n/a
OpenAPI description
See link above
Redocly Version(s)
latest (n/a)
Node.js
Version(s)n/a
Additional context
Noticed while debugging something unrelated.
The text was updated successfully, but these errors were encountered: