[BUG] endless loop in DefaultCodgegen updateAllModels with REF_AS_PARENT_IN_ALLOF=true

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Some (valid) openapi schemas fail the api client generation with any generator, because of an unfortunate naming collision in the component schemas with the REF_AS_PARENT_IN_ALLOF=true option.

The following line can return parent reference to itself, resulting in an endless loop with rapidly increasing heap memory until the process eventually dies with java.lang.OutOfMemoryError: Java heap space.

https://github.com/OpenAPITools/openapi-generator/blob/9ae877598713eff7c6b1bbb53c5b3b8ed22fa1f2/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java#L635

In the example that I am providing below, the issue appears because there is a model named ParentChild and there is a property child in a model named Parent (names chosen here for the minimal reproduction). In the provided example, the generator gets stuck because allModels.get(parent.getParent()) returns itself as a parent for a CodegenModel ParentChild.

I am not sure if this is a limitation of the normalizer implementation, or if this is simply something the generator cannot support. Either way, it would be good to detect such an endless loop and provide a helpful error message to the user. People that are in control of their api can then at least rename clashing properties.

openapi-generator version

7.7.0

OpenAPI declaration file content or url

https://gist.github.com/xfh/37c3fd48b2c2eab4c88ec2660bc27d30

Generation Details

see below. The only relevant setting is --openapi-normalizer REF_AS_PARENT_IN_ALLOF=true and the provided OpenAPI definition.

Steps to reproduce

run

npx @openapitools/openapi-generator-cli generate -i https://gist.githubusercontent.com/xfh/37c3fd48b2c2eab4c88ec2660bc27d30/raw/7d9afb6a76195f24aca255925da146041a489cbc/openapi.yml -g typescript-angular --openapi-normalizer REF_AS_PARENT_IN_ALLOF=true

I've also tested other generators, e.g. java

Related issues/PRs

I've run into this issue in a project with a java backend that is using smallrye-open-api-jaxrs 2.1.21 to generate the openapi schema. When I used a new quarkus project to provide a minimal reproduction, the error did not appear.

In https://github.com/smallrye/smallrye-open-api/issues/1180, version 3.1.0 and 2.1.23, the schema generation changed.
Instead of

    Parent:
      required:
      - child
      type: object
      properties:
        child:
          allOf:
          - $ref: '#/components/schemas/ParentChild'
          - nullable: false

it's generating without allof and not suffering from the same problem.

    Parent:
      required:
      - child
      type: object
      properties:
        child:
          $ref: "#/components/schemas/ParentChild"

Suggest a fix

I'd add a check after https://github.com/OpenAPITools/openapi-generator/blob/9ae877598713eff7c6b1bbb53c5b3b8ed22fa1f2/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java#L635

Something like

CodegenModel nextParent = allModels.get(parent.getParent());
if (parent.equals(nextParent)) {
    throw new RuntimeException("Normalization limitation: a model should not refer to itself. See github issue...");
}
parent = nextParent;

Maybe someone with more insights into the code finds a way to actually support such openapi definitions.

Start at modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java around the linked line and reproduce the failure with the provided gist and REF_AS_PARENT_IN_ALLOF=true command. Trace how allModels resolves parent references and determine the expected behavior when a model becomes its own parent. Done should include a regression check for the endless loop and a user-facing outcome for the invalid relationship.