[JsonSchema] v3.1.6 regression - modifying `output` to a DTO can cause infinite loop in schema types

[jamesisaac]

API Platform version(s) affected: 3.1.6 up to latest

Description

v3.1.6 has introduced an issue in how references in the JsonSchema are calculated, which can lead to incorrect types in the OpenApi schema (and ultimately an infinite loop of types).

• For one of the GET operations of my resource (GET /greetings/1), I want the output to be represented as a DTO which contains the resource itself, and some additional fields, so I set output: GreetingOverviewDto::class on the Operation.
• Starting in v3.1.6, the type given for the $greeting field in the OpenApi docs is incorrect - the schema states that its type is GreetingOverviewDto when it should be Greeting
• So as well as being incorrect type, it results in an infinite loop when trying to analyse the types, as it's referencing itself.

How to reproduce

I've created a minimal repro here: https://github.com/jamesisaac/apip-3.1.6-bug-jsonschema

Open up http://localhost:8000/docs.json and look at the following location in the json:

paths:
  /greetings/{id}:
    get:
      responses:
        200:
          content:
            application/ld+json
              schema:
                $ref: "#/components/schemas/Greeting.GreetingOverviewDto.jsonld-Advanced"

components:
  schemas:
    Greeting.GreetingOverviewDto.jsonld-Advanced:
      properties:
        greeting:
          $ref: "#/components/schemas/Greeting.GreetingOverviewDto.jsonld-Advanced"

The above is self-referencing back to the DTO.

Downgrade to 3.1.5 and it works correctly:

$ref: "#/components/schemas/Greeting.jsonld-Advanced"

Possible Solution

Specifically, this PR seems to have introduced the issue: https://github.com/api-platform/core/pull/5469

By reverting the changes to SchemaFactory, it starts working again.

[sergiuionescu]

Although I tend to agree with @jamesisaac and the straightforward solution here would be a revert, I've added a PR with a patch that allows DTO wrappers to properly resolve the documentation when the wrapped class ApiResource does not have a custom shortName.

I believe that the question here is if we want the documentation to follow ApiResource definition as opposed to just serialisation groups when nesting ApiResources or Dtos with ApiResources.

Anyway @soyuka please take a look at the new test case and the fix and let me know if you think this can be a good compromise.

PS - there is a failing PHPUnit test that i will further investigate we consider this to be in the right direction.