Open andersk opened 1 year ago
Hi @andersk
thanks for the report. This one will require type finding in AnyCaster
implementation right after ObjectCaster
.
Unfortunately it's not so straightforward to make it work soon.
Hmm, I can see why this would be difficult. There are some questions here that the specification doesn’t seem to address; for example, if a path or query value 123
validates as both {"type": "integer"}
(with casting) and {"type": "string"}
(without casting), should it also validate as {"allOf": [{"type": "integer"}, {"type": "string"}]}
, even though one would expect that to be self-contradictory in the ordinary JSON schema sense? I’m not sure what the right answer is.
Do you happen to know what part of the specification allows a path or query value 123
to validate as {"type": "integer"}
in the first place? It’s certainly convenient and what I’d expect without trying to lawyer too hard, but I haven’t found a justification for it in the specification.
Hello, what is the state of this issue? We are interested in using this for openapi validations but due to the still existing problem mentioned in the OP we unfortunately cannot really use this.
Actual Behavior
The string
123
from a path or query parameter validates as{"type": "integer"}
, but unexpectedly fails to validate as{"allOf": [{"type": "integer"}]}
. The same problem occurs withnumber
orboolean
in place ofinteger
, oranyOf
oroneOf
in place ofallOf
.(My actual use case involves
{"oneOf": [{"type": "string", "enum": ["newest", "oldest", "first_unread"]}, {"type": "integer"}]}
.)Expected Behavior
No error. A string that validates as
{"type": "integer"}
should also validate as{"allOf": [{"type": "integer"}]}
.Steps to Reproduce
OpenAPI Core Version
0.18.1 or current Git (0838a84e7c23d9f0691e0e7d496550d12513476e)
OpenAPI Core Integration
none
Affected Area(s)
No response
References
No response
Anything else we need to know?
No response
Would you like to implement a fix?
None