You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Essentially what I try to express is that recent_message can be either null or an object of type Message.
When I run a validator it raises an exception:
openapi_core.unmarshalling.schemas.exceptions.InvalidSchemaValue: Value {
'results': [{'uid': '018a8f79-5098-478b-a77e-2adb685a1ea5', 'recent_message': None}]
} not valid for schema of type object: (<ValidationError: 'None for not nullable'>
After debugging the issue I have been able to find the root cause. I think the main reason why it happens is that openapi-schema-validator adds a "nullable": false to each ref. So the actual schema that ends being used is the following:
{'nullable': False,
'properties': {'recent_message': {'allOf': [{'$ref': '#/components/schemas/Message',
'nullable': False, # <---- this is what triggers the wrong error
'x-scope': ['',
'#/components/schemas/GroupWithRecentMessage']}],
'nullable': True,
'readOnly': True},
'uid': {'format': 'uuid',
'nullable': False,
'readOnly': True,
'type': 'string'}},
'required': ['recent_message',
'uid'],
'type': 'object'}
OpenAPI 3.0.x needs special hacks for nullable with enum (1, 2, 3)
This breaks nullable set to True alongside allOf/anyOf/oneOf. (This is your case @knivets.)
The comment # append defaults to trigger validator (i.e. nullable) doesn't seem to make sense as validation seems to work perfectly fine without it. Perhaps @p1c2u can shed some light on why this is/was necessary?
This shouldn't be an issue with OpenAPI 3.1.x when it is supported as null is allowed as a type.
I have used the following workaround which may help:
fromopenapi_core.unmarshalling.schemas.enumsimportUnmarshalContextfromopenapi_core.unmarshalling.schemas.factoriesimportSchemaUnmarshallersFactoryfromopenapi_core.validation.response.validatorsimportResponseValidatorfromopenapi_schema_validatorimportOAS30ValidatorclassFixedOAS30Validator(OAS30Validator):
defiter_errors(self, instance, _schema=None):
# Use the implementation of .iter_errors() from the parent.returnsuper(OAS30Validator, self).iter_errors(instance, _schema)
classFixedSchemaUnmarshallersFactory(SchemaUnmarshallersFactory):
defget_validator(self, schema):
kwargs= {"resolver": self.resolver, "format_checker": self.format_checker}
ifself.contextisnotNone:
kwargs[self.CONTEXT_VALIDATION[self.context]] =Truewithschema.open() asschema_dict:
returnFixedOAS30Validator(schema_dict, **kwargs)
classFixedResponseValidator(ResponseValidator):
@propertydefschema_unmarshallers_factory(self):
returnFixedSchemaUnmarshallersFactory(
self.spec.accessor.dereferencer.resolver_manager.resolver,
self.format_checker,
self.custom_formatters,
context=UnmarshalContext.RESPONSE,
)
That's exactly what comment says to trigger nullable validator.
The comment # append defaults to trigger validator (i.e. nullable) doesn't seem to make sense as validation seems to work perfectly fine without it.
It can work fine if you define nullable param explicitly.
For schema without nullable defined (default is False) if you pass None value it won't raise validation error - which is incorrect. You can try to remove these lines and run tests.
There were ambiguities in the semantics of nullable in OAS 3.0.0-2 More about the issue can be found in the following proposal. OAS 3.0.3 clarified the definition so it can be implemented properly. There shouldn't be any major backward compatibility issues.
Activity
ngnpope commentedon Oct 11, 2021
I have also bumped into this issue. I believe that these lines are incorrect and should be removed:
https://github.com/p1c2u/openapi-schema-validator/blob/ab7222af0597ebc672f93cc7f7e089897aba1bec/openapi_schema_validator/validators.py#L68-L72
This is for a number of reasons, all of which have affected me:
$ref(1)nullablewithenum(1, 2, 3)nullableset toTruealongsideallOf/anyOf/oneOf. (This is your case @knivets.)The comment
# append defaults to trigger validator (i.e. nullable)doesn't seem to make sense as validation seems to work perfectly fine without it. Perhaps @p1c2u can shed some light on why this is/was necessary?This shouldn't be an issue with OpenAPI 3.1.x when it is supported as
nullis allowed as a type.I have used the following workaround which may help:
claeyswo commentedon Feb 8, 2022
We are experiencing the same issue. As the previous comment stated: Perhaps @p1c2u can shed some light on why this is/was necessary?
p1c2u commentedon Feb 10, 2022
That's exactly what comment says to trigger nullable validator.
It can work fine if you define
nullableparam explicitly.For schema without
nullabledefined (default isFalse) if you passNonevalue it won't raise validation error - which is incorrect. You can try to remove these lines and run tests.ngnpope commentedon Feb 10, 2022
Maybe the issue I was bumping into was related to #24 (solved by #26), but I haven't been able to check.
p1c2u commentedon Feb 10, 2022
Same here, can't reproduce the issue. @claeyswo which jsonschema version you use and do you have any example of the issue?
claeyswo commentedon Feb 14, 2022
3.0, but by adding nullable to every item the problem was solved. By switching the nullable om some_id in the example below we get the desired effect.
ghandic commentedon Jun 23, 2022
Neither work, any update on a fix for this?
tests: Add test for nullable refs
Fix python-openapi#20 - nullable semantics with $ref, oneOf, anyOf, a…
Fix python-openapi#20 - nullable semantics with $ref, oneOf, anyOf, a…
Fix python-openapi#20 - nullable semantics with $ref, oneOf, anyOf, a…
p1c2u commentedon Jan 7, 2023
There were ambiguities in the semantics of
nullablein OAS 3.0.0-2 More about the issue can be found in the following proposal. OAS 3.0.3 clarified the definition so it can be implemented properly. There shouldn't be any major backward compatibility issues.Merge pull request #57 from pyckle/master