JSON:API included compound documents no longer represented in OpenAPI output in 4.3.x

[cay89]

Description

After upgrading from API Platform 4.1.x to 4.3.x (Laravel port, JSON:API format), the generated OpenAPI documentation no longer appears to represent JSON:API compound documents (included) when using the include query parameter.

In previous versions, the generated response examples appeared to include an included top-level member when the endpoint supported include.

In 4.3.x this is no longer present (at least in our setup), and the generated OpenAPI schema/examples now only describe:

{
  "data": [...]
}

while the actual runtime response may still legitimately contain:

{
  "data": [...],
  "included": [...]
}

Why this matters

This is problematic when using generated API clients based on the OpenAPI contract.

Many generators (TypeScript, Kotlin, Swift, C#, etc.) produce strict models from the schema. If the OpenAPI document does not represent the possible included member, generated clients may:

• ignore the field,
• fail deserialization,
• or otherwise not correctly handle valid runtime responses.

From a JSON:API perspective, included is not an arbitrary extension field, but part of the official compound document structure.

Questions

• Is this an intentional change in 4.3.x?
• Is OpenAPI generation for JSON:API compound documents currently considered unsupported / best-effort?
• Or could this be a regression introduced during OpenAPI generation refactoring?

Additional context

We can work around this on our side with custom OpenAPI decoration, but we would like to understand the intended behavior and whether the current schema generation is considered correct by the maintainers.

Thanks!