genId false trigger an error on openapi
API Platform version(s) affected: 3.4.* (looking at the code, could be also 4.* but not tested)
Description
Having a resource which has a sub resource with a ApiProperty's genId at false generates an error while using command api:openapi:export:
In SchemaFactory.php line 240:
Notice: Indirect modification of overloaded element of ArrayObject has no effect
How to reproduce
That's the issue, I don't know how I ended up with this. I tried to replicate this in a fresh APIP 4.1 distrib, but didn't manage to. I didn't find a 3.4 distrib to test on a clean environment, so I tried to replicate on some professional project.
Investigating via step debug, it seems related to both sub resources and the presence of normalizationContext.
It's like the SchemaFactory generates a sub schema (v3.4 l231) of the sub resource that doesn't contains @id (due to serialization groups?) and then tries to delete it (v3.4 l240) but the @id is not existing then triggering the error.
Possible Solution
In the JsonSchema/SchemaFactory (v3.4 l240, v.4.0 l230, v4.1 l229), add in the condition before removing the @id part, a test of the key to delete:
if (
isset($subSchema->getDefinitions()[$subDefinitionName])
&& isset($subSchema->getDefinitions()[$subDefinitionName]['properties']['@id'])
) {
unset($subSchema->getDefinitions()[$subDefinitionName]['properties']['@id']);
}
I can do a PR to fix it, but as I wasn't enable to reproduce it outside of 3.4 I wanted to have some external feedback (cc @soyuka)
Additional Context
Full error:
Error thrown while running command "api:openapi:export --output='docs/swagger_docs.json'". Message: "Notice: Indirect modification of overloaded element of ArrayObject has no effect" ["exception" => ErrorException { …},"command" => "api:openapi:export --output='docs/swagger_docs.json'","message" => "Notice: Indirect modification of overloaded element of ArrayObject has no effect"]
In SchemaFactory.php line 240:
Notice: Indirect modification of overloaded element of ArrayObject has no effect
api:openapi:export [-y|--yaml] [-o|--output [OUTPUT]] [--spec-version [SPEC-VERSION]] [--api-gateway]
The quoted code was introduced by 99262dce739800bd841c95e026848b587ba25801, which focus on command api:json-schema:generate, but make api:openapi:export fail in the above situation.
I think that https://github.com/api-platform/core/pull/6960 fixes the issue.
3.4 isn't maintained anymore we focus only on 4.1 and 4.0 (security fixes)
I think that #6960 fixes the issue.
3.4 isn't maintained anymore we focus only on 4.1 and 4.0 (security fixes)
Indeed, the unset code is not there anymore.
I admit that's a huge refactor (well done) for me to understand clearly 😅
Will the #[ApiProperty(genId: false)] still be handled with this PR?
What's locking you in 3.4 ? I'd be glad to accept a fix in 4.1 as 4.2 is only planned in September.
This issue still occurs on api-platform/json-schema v4.1.17:
/**
* @var Collection<int, WalkerInterface>|null
*/
#[Serializer\Groups(['web_response'])]
#[ApiProperty(
identifier: false,
genId: false,
)]
private ?Collection $blocks = null;
{
"@context": "/api/contexts/Error",
"@id": "/api/errors/500",
"@type": "hydra:Error",
"title": "An error occurred",
"detail": "Notice: Indirect modification of overloaded element of ArrayObject has no effect",
"status": 500,
"type": "/errors/500",
"trace": [
{
"file": "/app/vendor/api-platform/json-schema/SchemaFactory.php",
"line": 139,
"function": "buildPropertySchema",
"class": "ApiPlatform\\JsonSchema\\SchemaFactory",
"type": "->"
},
{
"file": "/app/vendor/api-platform/hydra/JsonSchema/SchemaFactory.php",
"line": 74,
"function": "buildSchema",
"class": "ApiPlatform\\JsonSchema\\SchemaFactory",
"type": "->"
},
{
"file": "/app/vendor/api-platform/json-schema/BackwardCompatibleSchemaFactory.php",
"line": 38,
"function": "buildSchema",
"class": "ApiPlatform\\Hydra\\JsonSchema\\SchemaFactory",
"type": "->"
},
{
"file": "/app/vendor/api-platform/openapi/Factory/OpenApiFactory.php",
"line": 265,
"function": "buildSchema",
"class": "ApiPlatform\\JsonSchema\\BackwardCompatibleSchemaFactory",
"type": "->"
},
pr very welcome
What's locking you in 3.4 ? I'd be glad to accept a fix in 4.1 as 4.2 is only planned in September.
Hi @soyuka, sorry, didn't see the notification. It's clearly a lack of time, but I started advocating for upgrading at my work.
Based on @ambroisemaupate comment, I'll see if I can reproduce it and open a pr.