Stack overflow when using the OpenAPI generator

Georg · 2024-10-01 14:04:35

Hello,

first of all, thanks for the new OpenAPI generator. It's really great that there is a fully open source OpenAPI generator for Pascal/Delphi now.

I have a small project with an OpenAPI specification that unfortunately causes a stack overflow in the mORMot OpenAPI generator, the spec file is here:

https://gist.github.com/georgkeller/ad9 … d913081301

I used the following call (the exe was compiled with Delphi 12.2 for Win64):

.\mopenapi.exe .\testapi.json Test

The code generation for other languages with the opencollective openapi_generator works (tested with go, rust, javascript).

ab · 2024-10-02 07:02:09

There is a magnificent infinite recursion in

components": {
      "schemas": {
        "Group": {
          "type": "object",
...
            "Groups": {
              "type": "array",
              "items": {
                "$ref": "#/components/schemas/Group"
              }
            }
          }
        },

I don't even know how to define this in pascal types.
With record/arrays, I guess we can't:

TGroup = record 
  Name: string;
  Items: TItemDynArray;
  Groups: TGroupDynArray;
end;

but we can't define the TGroupDynArray type before finishing the TGroup type definition.
So we have to define:

Groups: array of TGroup;

But it does not compile on Delphi 7/2007. Only FPC and newer Delphi do accept this definition.

I guess the most simple solution is to define this Groups recursive field as variant, and fill it with JSON.

ab · 2024-10-02 07:32:34

How was this API definition generated?

Some of the internal details are weird:
- the nested types are not defined in logicial order (the dependency tree is not followed)
- it uses 'application/json; charset=utf-8' instead of the standard 'application/json'

Georg · 2024-10-02 11:01:07

Thanks for your analysis.

The API definition was generated by a webservice written in Rust (using the poem_openapi crate).
The order of the types in the spec is not the same as the order of their definitions in the source code, so I would assume that the order is decided in the poem_openapi crate.
The usage of "charset=utf-8" in the spec seems to originate in the poem_openapi library, I have not yet found a way to change that.

I checked my API with two validation tools, it is a valid OpenAPI specification.

Last edited by Georg (2024-10-02 13:06:03)

ab · 2024-10-02 14:29:59

This generator seems weird. The most unexpected is nested $ref definitions.

Please try with my latest commits.
The nested $ref definitions will now be accepted, and generated as "array of" within the record itself, or a plain variant on Delphi 7/2007, which does not support this syntax.

Now there is no issue on your API definition any more: on my side, it can generate the proper pascal client code:
https://gist.github.com/synopse/41fce67 … 7074e3740c

Feel free to come back if you have any other issue.

ab · 2024-10-03 15:30:55

Also a lot of fixes today, with a huge API definition coming from a huge DotNet project.

Recursive nested types seem to be detected properly now.
Also a lot of fixes about enums and sets, and better parameter support.

Feedback is welcome!

Georg · 2024-10-04 11:21:43

The generation of the client code now works and I was able to use the client code to interact with the api.
Thanks for your quick corrections and for your OpenAPI converter, great work .

mORMot Open Source

#1 2024-10-01 14:04:35

Stack overflow when using the OpenAPI generator

#2 2024-10-02 07:02:09

Re: Stack overflow when using the OpenAPI generator

#3 2024-10-02 07:32:34

Re: Stack overflow when using the OpenAPI generator

#4 2024-10-02 11:01:07

Re: Stack overflow when using the OpenAPI generator

#5 2024-10-02 14:29:59

Re: Stack overflow when using the OpenAPI generator

#6 2024-10-03 15:30:55

Re: Stack overflow when using the OpenAPI generator

#7 2024-10-04 11:21:43

Re: Stack overflow when using the OpenAPI generator

Board footer