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
Properties with multiple type unions generate incorrect OpenAPI schema #6212
Comments
Hi could you open a PR? |
Fixed in #6223 |
@soyuka I've found more issues related to this that are probably worth fixing before the next release. I've created a branch that I'll use to PR with two unit tests to illustrate the problem(s): https://github.com/GwendolenLynch/api-platform-core/tree/fix/issues/6212 These two will produce incorrect schema output: #[ApiProperty]
public ?Book $reference;
// The integer is stored in the database, and a state provider transforms the integer into the Species class
#[ApiProperty]
public int|Species|null $species = null; "species": {
"oneOf": [
{
"type": [
"string",
"null"
],
"format": "iri-reference",
"example": "https://example.com/"
},
{
"type": [
"integer",
"null"
]
}
]
},
"reference": {
"type": [
"string",
"null"
],
"format": "iri-reference",
"example": "https://example.com/"
} |
Looks okay to me |
Me too! 😵💫 I was trying to "simplify" the use/test case that I had, but went too far … The "looking at the problem too long" thing again. However, putting the serialization group back in shows the problem I am trying to illustrate: // The integer is stored in the database, and a state provider transforms the integer into the Species class
#[ApiProperty]
#[Groups(['read'])] // also applied to the properties in the Species class
public int|Species|null $species = null; Snippet of the output. Note the presence of "species": {
"oneOf": [
{
"type": [
"unknown_type",
"null"
]
},
{
"type": [
"integer",
"null"
]
}
]
} |
API Platform version(s) affected: 3.2
Description
Currently (3.2.16) with the model below the
owner
property will generate the schema:Instead of:
How to reproduce
Possible Solution
I dug in a bit and it stems from handling in
SchemaFactory::buildPropertySchema
. Simply removing the finalbreak
here make this particular problem disappear but breaks tests. So I hacked up a more robust proof-of-concept fix/patch below that addresses this issue (and passes existing tests).The text was updated successfully, but these errors were encountered: