Describe the bug
exclusiveMinimum and exclusiveMaximum should be of type boolean
To Reproduce
A field with greater than property is generated as:
end:
exclusiveMinimum: 0.0
type: number
Expected behavior
It should be:
end:
exclusiveMinimum: true
minimum: 0.0
type: number
Environment:
Additional context
According to OpenAPI, these fields should be boolean as listed here.
that's something that I found some time ago in the chat, and that's a weird one.
Effectively when you go into https://editor.swagger.io/ and try to validate a schema it says exclusiveMinimum and exclusiveMaximum should be of type boolean.
However when you're reeading the spec it's clear it's a number:
http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.2.5
by the way this PR tests all types and effectively we got hit as well copying the results of openapi.json into https://editor.swagger.io/
Thanks @euri10 !
Here's what I found after some investigation :mag:
I was about to say it's an error in Swagger Editor, and in the schema in the repo.
Because the OpenAPI spec declares to use the types from JSON Schema: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#properties
The following properties are taken directly from the JSON Schema definition and follow the same specifications.
And in JSON Schema: http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.2.5
The value of "exclusiveMinimum" MUST be number [...].
But...
But the issue is that OpenAPI says it's using the types in JSON Schema draft-00, which is an older version. The current one is draft-07.
Pydantic generates JSON Schema's using the latest version, draft-07. But OpenAPI is not updated to the most recent version. So, we have a version mismatch between JSON Schema versions and how they are used in OpenAPI.
I just asked about it here, so we can track what's the state of it in the spec itself: https://github.com/OAI/OpenAPI-Specification/issues/1466#issuecomment-493982877
I'm having this same issue which I discovered while trying to use schemathesis to run smoke tests.
BTW, new draf-08 is out (now called 2019-09). This issue is going to stick for a LOOOONG while I guess, until JSON schema lands on a stable version so as to the OpenAPI spec to pick up a new JSON schema. Damn!
Would it be viable to use a setting to pick which JSON schema we want to use when creating the app? it could default to the current, and perhaps begin by supporting current (07) and 00 (to solve issues like this one). What do you think @tiangolo ?
Hi @HacKanCuBa
For your information, I plan to work on having some compatibility shim in schemathesis. https://github.com/kiwicom/schemathesis/issues/503 to mitigate this issue.
This stricter behavior was introduced in Schemathesis 1.1.1, feel free to use an older version, e.g. 1.1.0 where schemas were converted to Draft 7 compatible.
There is another issue with mixing different drafts - integer type behavior. For example, 1.0 is an integer in Draft 6+, but is not in Draft 4 (and in draft‑wright‑json‑schema‑00). I assume that this is also applicable for Fast API / pydantic case.
begin by supporting current (07) and 00 (to solve issues like this one)
It seems like a nice idea, but folks from JSON Schema do not recommend implementing draft‑wright‑json‑schema‑00 (commonly known as Draft 5).
Implementors should not implement or advertise support for “draft-05”.
Implementations that supported “draft-05” by implementing proposals from right after the publication of draft-04 should either remove that support or give it a different name to avoid confusion.
Which is kinda weird, since Open API 3.0.x is based on this draft :/
Wow, what a mess! Anyhow, thank you for the info :dancers:
Lucky for me, the controversial exclusiveMin/Max parameter was only used in a single path operation so I currently just removed it and left an adequate comment, so it caused no harm for my case. But i'm really looking forward towards your solution :smile:
I've also run into this and did some heavy investigation into it in collaboration with @Stranger6667 yesterday to make sure that it's indeed a bug in FastAPI/pydantic and not schemathesis. Was going to post it as an issue here but now I see that there already is one.
From our investigations it was clear that the spec for OpenAPI 3.0.x which uses draft 4/json-schema-00 is to use an integer for exclusiveM... and not a boolean combined with minimum/maximum. However, the next version which is still WIP (OAS v3.1.0) will use the newer
JSON-Schema version and be compliant with current behaviour. So it would probably
be wise to keep the current behaviour behind a feature toggle or similar for when that is live.
Ah, great, I was going to post all that here, thanks @Hultner for doing that!
I'm sorry I didn't post it here before and you had to go through all the research to find that (or maybe I checked all that after this? :thinking: )
Anyway, just for completeness, now that we are talking about exact OpenAPI and JSON Schema correctness, these are the other small differences. Although they will all work the same in OpenAPI 3.1.0.
Tuple and several subtypes as in Tuple[str, int, bool]. As OpenAPI currently still doesn't support it, the way to be strict is to only declare List[SimpleType] and not tuples. In OpenAPI 3.1.0 it will be supported.example while JSON Schema uses examples. Both can be added to Pydantic/FastAPI, as it is done manually, extending the schema. It will be examples in OpenAPI 3.1.0.Here are more (technical) details: https://github.com/samuelcolvin/pydantic/issues/1478#issuecomment-633035797
Most helpful comment
I've also run into this and did some heavy investigation into it in collaboration with @Stranger6667 yesterday to make sure that it's indeed a bug in FastAPI/pydantic and not schemathesis. Was going to post it as an issue here but now I see that there already is one.
From our investigations it was clear that the spec for OpenAPI 3.0.x which uses draft 4/json-schema-00 is to use an integer for exclusiveM... and not a boolean combined with minimum/maximum. However, the next version which is still WIP (OAS v3.1.0) will use the newer
JSON-Schema version and be compliant with current behaviour. So it would probably
be wise to keep the current behaviour behind a feature toggle or similar for when that is live.
References