[BUG] Go generator results in missing objects when using oneOf interfaces - leads to import error

[rgomezp]

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

Similar to #6161 , the Go generator has a bug where "oneOf" spec definitions are resulting in missing objects that lead to errors.

We are willing to sponsor work on this issue to the tune of $100.

openapi-generator version

Using version 5.2.0

OpenAPI declaration file content or url

Thanks @wing328

      "InvalidIdentifierError": {
        "type": "object",
        "properties": {
          "invalid_external_user_ids": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "description": "Returned if using include_external_user_ids"
          },
          "invalid_player_ids": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "description": "Returned if using include_player_ids and some were valid and others were not."
          }
        }
      },
      "NoSubscribersError": {
        "type": "array",
        "items": {
          "type": "string"
        },
        "description": "Returned if no subscribed players.\n"
      },
      "Notification200Errors": {
        "oneOf": [{
          "$ref": "#/components/schemas/InvalidIdentifierError"
        },
        {
          "$ref": "#/components/schemas/NoSubscribersError"
        }]
      },

Generation Details

openapi-generator-cli generate -g go -i /parent/api.json -o /parent/build/go -c /parent/codegen/go.yml --git-user-id OneSignal --git-repo-id onesignal-go

go.yml:

disallowAdditionalPropertiesIfNotPresent: false
packageName: 'onesignal'
packageVersion: 1.0.0

Steps to reproduce

Related issues/PRs

#6161

Suggest a fix

Currently, building results in the following struct:

type Notification200Errors struct {
	InvalidIdentifierError *InvalidIdentifierError
	[]string *[]string    // <-- error
}

and the following functions:

// []stringAsNotification200Errors is a convenience function that returns []string wrapped in Notification200Errors
func []stringAsNotification200Errors(v *[]string) Notification200Errors {
	return Notification200Errors{ []string: v}
}

notice the function name []stringAsNotification200Errors leads to an error also.

Digging into the source code a bit, it looks like the problem occurs in model_oneof.mustache:

// {{classname}} - {{#description}}{{{description}}}{{/description}}{{^description}}struct for {{{classname}}}{{/description}}
type {{classname}} struct {
	{{#oneOf}}
	{{{.}}} *{{{.}}}
	{{/oneOf}}
}

{{#oneOf}}
// {{{.}}}As{{classname}} is a convenience function that returns {{{.}}} wrapped in {{classname}}
func {{{.}}}As{{classname}}(v *{{{.}}}) {{classname}} {
	return {{classname}}{ {{{.}}}: v}
}

{{/oneOf}}

In particular, this portion: {{{.}}} *{{{.}}} which results in the name and the type being the same. With my first model (InvalidIdentifierError) there is no issue since the model is it's own object with own definition. But in the second case (NoSubscribersError) the model is an array so I think it's not creating its own type.

The correct result would be something like:

type Notification200Errors struct {
	InvalidIdentifierError *InvalidIdentifierError
	NoSubscribersError *[]string    // <-- no error
}

---

Note, as of 3/9/22 I don't know what changed, but I have been unable to reproduce the above build where we get the:

type Notification200Errors struct {
	InvalidIdentifierError *InvalidIdentifierError
	[]string *[]string    // <-- error
}

I am back to getting the original issue where the Notification200Errors doesn't get generated -- an issue regardless.

[wing328]

@rgomezp thanks for sponsoring the fix. Basically the goal is to support non-model type (e.g. primitive type or array or primitive type) in the oneOf member in the Go client.

cc @antihax (2017/11) @grokify (2018/07) @kemokemo (2018/09) @jirikuncar (2021/01) @ph4r5h4d (2021/04)

[wing328]

UPDATE: I've filed #11863 to fix the issue.