v2 branch for OpenAPI 3.0 support treats null fields as missing
When trying to use the new OpenAPI 3.0 nullable feature, it seems that the current state of the v2 branch does not properly consume or apply this property.
It appears that when validating a request, a null
field value is treated as if the key itself is not present. This can lead to surprising validation results. For instance, the following schema...
{
"type": "object",
"properties": {
"foo": {
"type": "string",
"nullable": false
}
}
}
...will pass validation for { "foo": null }
, because "foo"
is not a required property and the null
value is considered as if the corresponding key doesn't exist.
The converse of this plays out similarly. The following schema...
{
"type": "object",
"properties": {
"foo": {
"type": "string",
"nullable": true
}
},
"required": [ "foo" ]
}
...will fail validation for { "foo": null }
, even though the schema says "foo"
can be null
.
Comments (4)
-
reporter -
reporter - changed status to open
-
Is the second really a bug?
If a field is required, according to OpenAPI, it may not be null.
I don't know if the propertynullable
beats the propertyrequired
. If not the SRV validates correctly.Nonetheless the first one really seems buggy.
-
- changed status to resolved
Available in v2.0.0-rc2
- Log in to comment
It looks like this may be party due to the call to
removeNullValuesFromTree
when evaluating thereadContent
method inside theSchemaValidator
class.