[BUG][TYPESCRIPT-FETCH] Bug generating Typescript when array has both "items" and "properties" attributes

[galamome]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• 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

Code generated with typescript-fetch generator is faulty when the OpenAPI specification contains an array type that has both properties and items attributes.

openapi-generator version

7.14.0

OpenAPI declaration file content or url

<script src="https://gist.github.com/galamome/e8a64d748f442bd23ed17841480a7b20.js"></script>

Generation Details

java -jar modules/openapi-generator-cli/target/openapi-generator-cli.jar generate \
-g typescript-fetch \
--additional-properties=supportES6=true,npmVersion=6.9.0,typescriptThreePlus=true \
-i ~/buildDev/bug_openapi/interface/openapi.json \
-o ~/buildDev/bug_openapi/typescript-client-test

Steps to reproduce

The file typescript-client-test/models/Errors.ts generated is faulty: Array<ModelError>FromJSON

export function ErrorsFromJSONTyped(json: any, ignoreDiscriminator: boolean): Errors {
    if (json == null) {
        return json;
    }
    return {        
        'errors': json['errors'] == null ? undefined : Array<ModelError>FromJSON(json['errors']),
    };
}

and

export function ErrorsToJSONTyped(value?: Errors | null, ignoreDiscriminator: boolean = false): any {
    if (value == null) {
        return value;
    }

    return {
        
        'errors': Array<ModelError>ToJSON(value['errors']),
    };
}

Related issues/PRs

No related issue found.

Suggest a fix

It seems that having both properties and items in an array type is valid, but the properties should be ignored.

If so, the code generated should be the same as the one generated by the OpenAPI Specification that does not have the properties attribute:

<script src="https://gist.github.com/galamome/ad0a885dd45d3833139a79354e214dd6.js"></script>

The desired generated code:

<script src="https://gist.github.com/galamome/c21c0e5c6145bf7103932020c2d97671.js"></script>

REMARK: I have tried to generate for both specifications (with and without properties attribute) with other generators. For C# language (csharp-functions generator) the models generated are exactly the same. For Java however the generated classes are not the same.

[galamome]

Sorry Gist embed did not work:

• specification that generates bad code: https://gist.github.com/galamome/e8a64d748f442bd23ed17841480a7b20
• desired generated code: https://gist.github.com/galamome/c21c0e5c6145bf7103932020c2d97671
• specification that generates good code: https://gist.github.com/galamome/ad0a885dd45d3833139a79354e214dd6

[Mattias-Sehlstedt]

Hi,

Could you provide a source for the expectations that the current array definition should be considered a proper definition? My current understanding is that if you want to define an array that is a defined object together with a new property then you would do so as

{
  type: array  
  items: 
    type: object
     properties:
       error_schema_with_property: ...
       error_ref: $ref
    }
}

I.e., you have to define it as an inline object with two properties. See this as a source for an array of something that is not a ref.

[galamome]

Hi,

This specification is valid even if its looks strange : specification that generates bad code: https://gist.github.com/galamome/e8a64d748f442bd23ed17841480a7b20
It belongs to the OpenAPI Specification of an API my application has to consume, and there is nothing I can do about it.

The Typescript code generated is faulty.

I think in case of type array, attribute properties should be ignored, because it corresponds to type object (https://swagger.io/docs/specification/v3_0/data-models/data-types/#arrays.

Question about the same strange kind of specification: https://stackoverflow.com/questions/68591911/how-do-i-interpret-this-openapi-array-definition-with-the-properties-keyword

To sum up, this definition:

"type": "array",
"properties": {
    "empty": {
        "type": "boolean"
    }
},
"items": {
    "$ref": "#/components/schemas/error"
}

should be considered as:

"type": "array",
"items": {
    "$ref": "#/components/schemas/error"
}

[Mattias-Sehlstedt]

The project is structured so that a specification is first interpreted into a Java representation within an OpenAPI class (done with swagger-code/swagger-parser). It is then normalized, where "oddities" and concepts that can be expressed in a simpler manner are converted. Then it is converted into a codegen representation, which expresses common attributes that can act as hooks for code concepts. This is then used in a mustache template which in turn becomes the generated code.

I would suggest investigating where the issue arises by debugging how the normalizer handles the odd array-schema (e.g., by creating a unit-test for it).

It is also possible to implement and inject your own Normalizer into the gradle task with NORMALIZER_CLASS if you were to find how the issue should/could be handled. But the preferred solution would of course be if the project could handle this for everyone.

[galamome]

My merge request was rejected: #21817

I don't have an opinion about where the normalisation should be done. Mattias-Sehlstedt commented in the bug report, and advised to put it in the normalizer since it solves an oddity.
My thought was to leave the possibility to opt in to apply the normalizer rule and remove this oddity.

Maybe in order to avoid to create another normalizer rule, I could modify my PR in order to leave it in the normalizer but make it default. The drawback is that we would loose the possibility to opt out (and keep the "properties" attribute for a schema other than object, which is the oddity).
Do you think that would fit ?

By the way, I think "additionalProperties" attribute also should be removed for a schema other than object. At least it is what modules/openapi-generator/src/main/java/org/openapitools/codegen/InlineModelResolver.java says.

Looking forward to solve this bug, thanks to your advice,

Guillaume