[BUG] [JAVA] UNKNOWN BASE TYPE when using allOf in request body schema declaration

[Emdee89]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?

Description

Code generation spills out:

[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] allOf with multiple schemas defined. Using only the first one: SomewhatIn1. To fully utilize allOf, please use $ref instead of inline schema definition
[WARNING] The following schema has undefined (null) baseType. It could be due to form parameter defined in OpenAPI v2 spec with incorrect consumes. A correct 'consumes' for form parameters should be 'application/x-www-form-urlencoded' or 'multipart/form-data'
[WARNING] schema: class ComposedSchema {
    class Schema {
        type: null
		...
		
[WARNING] codegenModel is null. Default to UNKNOWN_BASE_TYPE

Thereafter, we encounter compilation failures:
api/SomewhatApi.java:[7,71] cannot find symbol
  symbol:   class UNKNOWN_BASE_TYPE

openapi-generator version

• 3.3.4
• 4.0.0

Both versions are affected.

OpenAPI declaration file content or url

Gist URL:
https://gist.github.com/Emdee89/b3bcab67c46fd6c49d9282a528313990

Command line used for generation

Maven Plugin execution:

<plugin>
        <groupId>org.openapitools</groupId>
        <artifactId>openapi-generator-maven-plugin</artifactId>
        <version>4.0.0</version>
        <executions>
          <execution>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <inputSpec>${project.basedir}/src/main/resources/spec.yaml</inputSpec>
              <output>${project.basedir}</output>
              <generatorName>java</generatorName>
              <configurationFile>${project.basedir}/src/main/resources/api-options.json</configurationFile>
              <generateApiTests>false</generateApiTests>
              <generateModelTests>false</generateModelTests>
              <generateApiDocumentation>true</generateApiDocumentation>
              <generateModelDocumentation>true</generateModelDocumentation>
              <generateSupportingFiles>true</generateSupportingFiles>
              <apiPackage>api</apiPackage>
              <modelPackage>model</modelPackage>
              <invokerPackage>invoker</invokerPackage>
              <removeOperationIdPrefix>true</removeOperationIdPrefix>
              <generateAliasAsModel>true</generateAliasAsModel>
            </configuration>
          </execution>
        </executions>
      </plugin>

api-options.json:

{
  "java8" : true,
  "dateLibrary" : "java8",

  "serializableModel" : true,
  "booleanGetterPrefix" : "is",
  "hideGenerationTimestamp" : false,

  "library" : "resttemplate",
  "sourceFolder" : "/src/main/java"
}

Steps to reproduce

Execute the Maven Plugin with the execution configuration shown above.

Related issues/PRs

Related issues:
#2030
#185

Suggest a fix

The generator appears to lack a concept for creating base types for schemas being used in conjunction with allOf.

In related issues I found the recommendation to use allOf inline. I applied this workaround.
See this gist: https://gist.github.com/Emdee89/cd188cb35721b080c101cc10ee757189

####### Workaround

I basically introduced the model named Workaround that serves as a layer in between. I declared the allOf within Workaround instead of within responses of the endpoint.
When executing the code generation with this workaround, all warnings/errors from above are gone and the code compiles. However, the generated code looks unexpected.

See Workaround.java:

public class Workaround extends SomewhatIn1 implements Serializable {

Workaround extends SomewhatIn1, but it should also be in a relationship with SomewhatIn2.
Consequently, I cannot claim that this workaround solves the problem.

[wing328]

         'application/json':
            schema:
              required:
              - name
              - type
              $ref: "#/components/schemas/Workaround"
              #allOf:
              #- $ref: "#/components/schemas/SomewhatIn1"
              #- $ref: "#/components/schemas/SomewhatIn2"

I'm afraid that's not validated. The schema should be either a $ref or an inline schema.

in other words, the required properties (name, type) should be in the Workaround definition.

[Emdee89]

@wing328 Thanks for commenting.

The spec-workaround.yaml seems to be valid according to the Online Validator. You probably meant something else mentioning "not validated"?

Anyway, I changed the yaml so that I use only $ref. Does this look OK from an OpenAPI perspective?

Still, the generator generates the same code after adjusting my yaml according to this gist spec-workaround.yaml.

[wing328]

Let's have a chat via https://gitter.im (ID: wing328) when you've time.

[Emdee89]

@wing328: Alright, I will approach you next week Monday or Tuesday.

[wing328]

I did a test and got the following "Workaround" class (which does not extend other class):

@ApiModel(description = "A representation of a workaround")
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaClientCodegen", date = "2019-06-03T23:17:47.966+08:00[Asia/Hong_Kong]")
public class Workaround {
  public static final String SERIALIZED_NAME_ID = "id";
  @SerializedName(SERIALIZED_NAME_ID)
  private String id;

  public static final String SERIALIZED_NAME_LABELS = "labels";
  @SerializedName(SERIALIZED_NAME_LABELS)
  private Map<String, List<String>> labels = new HashMap<String, List<String>>();

  public Workaround id(String id) {
    this.id = id;
    return this;
  }

[Emdee89]

@wing328 Thanks. Can you tell how your spec looked like and which options you passed to the generator?

[simion96]

Bump. I'm having similar issues with code generation on java with the same error. Schema is defined very similarly to OP's, and I just cannot get it to work. The only difference is that mine is not defined in the requestbody, just as a normal schema.

[reynoldsdj]

Same here, in request body; mine is autogenerated on the server side, so I don't have a lot of control over it:

This fails:

        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "title": "Payload",
                "allOf": [
                  {
                    "$ref": "#/components/schemas/PartitionModel"
                  }
                ],
                "description": "The record you wish to update"
              }
            }
          },
          "required": true
        }

This parses correctly:

        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "$ref": "#/components/schemas/PartitionModel"
              }
            }
          },
          "required": true
        }

[tejarao25]

Any update on this issue?

[Song2017]

This is a workaround, works for me, transfer inline required field to a new Model

    WorkaroundRequired:
      title: WorkaroundRequired
      type: object
      required:
        - name
        - type
      properties:
        name:
          type: string
        type:
          type: string

    Workaround:
      allOf:
        - $ref: "#/components/schemas/WorkaroundBase"
        - $ref: "#/components/schemas/WorkaroundRequired"
      title: Workaround

[Burimcakolli]

Any update on this issue?

[duhseekoh]

Same problem for typescript generators as well.

[MaximLopatin]

Any updates on the issue?

[JustASquid]

Ran into this issue myself using the Typescript generator from a swagger document generated by .NET Core Swashbuckle with config option c.UseAllOfToExtendReferenceSchemas().

[nurgasemetey]

It seems that javascript generator also adds this UNKNOWN_BASE_TYPE

UPDATE
Nevermind, problem was with endpoint itself which accepts multiple files on Spring Boot and Spring fox was generating not valid swagger.yml

[jfeltesse-mdsol]

Probably the same issue as I described in #5903, basically wherever allOf/anyOf/oneOf are used inline (e.g. without a named schema) the generator forgets to generate the model (even though it comes up with a name and adds references in the generated code for it).

[rockymontana]

I get this UNKNOWN_BASE_TYPE for every item I have in my requestBodies.
If I inline the request I get an InlineObject which is very anonymous.

I don't know what the idea is for these two use cases, but would it make sense to generate the classes from requestBodies outside of < modelPackage >, maybe as a < requestPackage >?

[tfabien]

As a workaround, I use jq to combine the àllOf children schemas into one single anonymous schema
As long as all schemas are not refs, this seems to work for me

# Replace all { "schema": "allOf": [ { /* obj1.prop1, obj1.prop2, ... */}, { /* obj2.prop1, ... */ }, ... ] } with { "schema": { obj1.prop1, obj1.prop2, obj2.prop1, ... } }
walk(if type == "object" and has("allOf") then . |= reduce .allOf[] as $it ({ }; . * $it) else . end)

Not really a fix, but I hope this could help someone in a pinch...

[micbar]

any news on this?

this seems to be still broken.

i am using the described workaround. Would be happy to get any pointers how to fix it.

[wing328]

This should be fixed via #12353. Please pull the latest master to give it a try.

[wing328]

Happy to reopen if it's still an issue.