Cannot generate files

[Leastrio]

Experimenting with this library using the discord api spec. I run the mix api.gen default ... command and after a while nothing happens but I get this error: fish: Job 1, 'mix api.gen default openapi3_1.…' terminated by signal SIGKILL (Forced quit)

One thing I notice is that my mem usage goes to 100%, its possible BEAM is just taking all of my memory up because of how big the discord spec is.

[AJ Foster]

That's not great. Could you link me to the spec you're using? Just want to make sure I try the exact same file. Thanks!

[Leastrio]

https://github.com/discord/discord-api-spec/blob/main/specs/openapi.json

At peak its taking about 64gb of ram and I think a bit of swap

[AJ Foster]

The good news is, I can replicate the issue. The bad news is, it still happens in the latest release candidate. Out of sheer curiosity, I let it run for a while to see if it would eventually terminate — after 112Gb of RAM, it still wasn't done. This suggests that there is a cycle in the referenced schemas (ex. users have teams, and teams have users) and the generator doesn't detect the duplication. Looking into this further.

[AJ Foster]

It looks like the Discord OpenAPI spec has this little gem:

{
  "components": {
    "schemas": {
      "ErrorDetails": {
        "oneOf": [
          {
            "type": "object",
            "additionalProperties": {
              "$ref": "#/components/schemas/ErrorDetails"
            }
          },
          {
            "$ref": "#/components/schemas/InnerErrors"
          }
        ]
      }
    }
  }
}

To be honest, I'm not sure what the resulting code should look like in this scenario. Their Postman collection seems to allow for any arbitrary JSON with this.

There is a (rather big) problem with the generator and how it (doesn't) handle cycles in the spec, which I'm working to resolve now. However, it might be worth finding out what Discord's intent with this field is.

[AJ Foster]

Version 0.1.0-rc.3 (note: major breaking change from 0.0.8) includes a fix for the cyclical reference issue. The ErrorDetails schema remains incomplete, but you might choose to ignore this schema using the available configuration. Please give it a try when you have a chance, and let me know how it goes!

[Leastrio]

This worked pretty well! Hopefully gonna save me a lot of time with my lib. One thing I maybe suggest is adding more logs that way people know stuff is happening instead of just waiting there. How do the api endpoints work? I see something about a client but I couldnt find a client file generated, do I have to make one myself?

[Leastrio]

I also believe that error schema just means it can be nested of itself? Very strange struct but could just be represented by __MODULE__.t() | InnerError right?

[AJ Foster]

We should definitely be able to include the | InnerError.t() portion of the spec as you suggested. I think the first part would need to be "a map with any arbitrary keys, as long as the values are t()." It might be within the realm of possibility for the generator to handle additionalProperties like this:

%{optional(String.t()) => t()} | InnerError.t()

[AJ Foster]

Quick update for anyone watching:

Version 0.1.0 gets a little closer to what we want (I think). It doesn't quite support additionalProperties fully, so ErrorResponse is emitted with an errors key that gets written as an empty schema called ErrorResponseErrors. The next step is to properly deal with additionalProperties when it is expressed as a schema or ref.