bug/regression: latest yams results in incomplete generation of types about swift-openapi-generator

[mwildehahn]

I was able to work around this just by post-processing the schema to handle removing those anyOf types 👍

[IanHoar]

Also having this issue. I'm using the schema directly from a django-ninja backend and it writes nullable types in the anyOf style. I'm getting dozens of warnings like Schema "null" is not supported, reason: "schema type" when generating. I'd like to not have to go trough and rewrite those optionals every time I update the schema.

Update: Forced Yams v5.0.6 in my Package.swift and generation is working now

Update 2: Generation worked, but now the app crashes when trying to parse the values that are defined in that anyOf style instead of the type style:

image_large_url:
  anyOf:
    - type: string
    - type: 'null'

needs to be this ⬇️

image_large_url:
  type: [string, 'null'] 

Update 3: Seems either is correct according to the OpenAPI maintainers: OAI/OpenAPI-Specification#3148

[czechboy0]

Hi @dpasirst,

this sounds very similar to #553.

I looked at your doc, and I think the problem is that we're not handling the case of anyOf where one of the cases is just null. In Swift, it's not necessary to have that explicit null, because the fact that phoneNumber already is omitted from required in the Account schema, we'll already treat it as optional.

So in your case, if you edit:

                    "phoneNumber": {
                        "description": "phone number",
                        "anyOf": [
                            {
                                "$ref": "#/components/schemas/PhoneNumber"
                            },
                            {
                                "type": "null"
                            }
                        ]
                    },

to:

                    "phoneNumber": {
                        "description": "phone number",
                        "$ref": "#/components/schemas/PhoneNumber"
                    },

It should start working again. Please let me know if that fixed it 🙂

[dpasirst]

Hi @czechboy0 ,
To answer your question, it partially fixes it but not super friendly.

With your suggested change and yams 5.1.X, phoneNumber does indeed appear; however, it is of type OpenAPIValueContainer? and not type PhoneNumber as I would have expected.

In the original example (unmodified) with yams 5.0.X, phoneNumber is of type Components.Schemas.NewAccount.phoneNumberPayload? which is not ideal (would be nicest to just be PhoneNumber directly), but still easier to work with than OpenAPIValueContainer?.

Regards.

[czechboy0]

That's strange, I would expect it to be of the PhoneNumber type. Can you post your updated OpenAPI doc here again please?

[dpasirst]

@czechboy0 - as requested - openapi.json with the change you suggested applied in 2 places:
openapi.json

[czechboy0]

@dpasirst Your OpenAPI JSON file seemed malformed, in both places you had:

"phoneNumber": {
    "#/components/schemas/PhoneNumber",
    "description": "phone number"
},

but should be:

"phoneNumber": {
    "$ref": "#/components/schemas/PhoneNumber",
    "description": "phone number"
},

When the generator runs, it emits warning and error diagnostics, can you check if it caught the malformed JSON? It's possible it didn't regenerate, showed an error, so your generated files would still be the old ones.

[dpasirst]

@czechboy0 - great catch. I see that was caused by my manual edit to change the json per a few comments back, I seem to have been a little too aggressive in removing the "anyOf"... I was not sure where to look for the generator error diagnostic. With the errored json, the Xcode build screen does not seem to indicate such a diagnostic, instead, it lists "- Diagnostics output path: <none - logs to stderr>".

Indeed, this:

"phoneNumber": {
    "$ref": "#/components/schemas/PhoneNumber",
    "description": "phone number"
},

does appear to work with both yams 5.0.X and 5.1.X.

In this case, the original posted json containing the anyOf is generated from a Rust project using Aide...and as already demonstrated manual editing is error-prone and less than ideal. Is this something that needs to be fixed upstream in that project or here on the client side?

In reviewing, #553 , it seems the Aide generated openapi.json might be valid as it is generating with the "null" as quoted.

[mwildehahn]

👋 I think I'm running into something similar with these warnings: Schema "null" is not supported, reason: "schema type", skipping

With something like this schema:

      "Cursors": {
        "properties": {
          "next": {
            "anyOf": [
              {
                "type": "string"
              },
              {
                "type": "null"
              }
            ],
            "title": "Next"
          },
          "previous": {
            "anyOf": [
              {
                "type": "string"
              },
              {
                "type": "null"
              }
            ],
            "title": "Previous"
          }
        },
        "type": "object",
        "required": [
          "next",
          "previous"
        ],
        "title": "Cursors"
      },

I understand from reading a couple issues that the recommendation is to not include {"type": "null"} but I don't have direct control over this. This is a side effect of using pydantic + fastapi and dumping the openapi schema. In this specific case, I'm also relying on returning "null" although I could work around it if need be.

[dpasirst]

for me, I can move forward for now thanks to @czechboy0 , but given the openapi.json is server generated, I'm hoping the fix to properly support the schema will not be too complicated and hopefully can be resolved quickly.