NullPointerException when generating TS29598_Nudsf_DataRepository as go-gin-server

[DonRichie]

Hello,

I am trying to generate server boilerplate code of the TS29598_Nudsf_DataRepository.yaml. Unfortunately I get a NullPointerException when doing so.

I want to generate as go-gin-server, but python-flask did produce the same error.
Generating the TS29598_Nudsf_Timer.yaml works, but the DataRepostory doesn't.

Does someone know why this Error happens and is able to fix it?

Command:

openapi-generator-cli generate -g go-server --additional-properties=prependFormOrBodyParameters=true -o out -i TS29598_Nudsf_DataRepository.yaml

Error:

Exception: null
	at org.openapitools.codegen.DefaultGenerator.processOperation(DefaultGenerator.java:1163)
	at org.openapitools.codegen.DefaultGenerator.processPaths(DefaultGenerator.java:1054)
	at org.openapitools.codegen.DefaultGenerator.generateApis(DefaultGenerator.java:549)
	at org.openapitools.codegen.DefaultGenerator.generate(DefaultGenerator.java:891)
	at org.openapitools.codegen.cmd.Generate.execute(Generate.java:441)
	at org.openapitools.codegen.cmd.OpenApiGeneratorCommand.run(OpenApiGeneratorCommand.java:32)
	at org.openapitools.codegen.OpenAPIGenerator.main(OpenAPIGenerator.java:66)
Caused by: java.lang.NullPointerException
	at org.openapitools.codegen.DefaultCodegen.getContent(DefaultCodegen.java:6743)
	at org.openapitools.codegen.DefaultCodegen.fromOperation(DefaultCodegen.java:4006)
	at org.openapitools.codegen.DefaultGenerator.processOperation(DefaultGenerator.java:1131)
	... 6 more

[DonRichie]

I believe the responses are the problem:

      responses:
        '200' : #result ok
          $ref: '#/components/responses/RecordBody'

If I swap the above lines in a limited example with a another schema, for example like this:

      responses:
        '200':
          description: Successful case. Response contains result of the search.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecordSearchResult'

Then it works.

[DonRichie]

If I further swap

$ref: '#/components/responses/RecordBody'

with

$ref: '#/components/schemas/RecordBody'

It works. But only in my limited example. Not the full spec.

Please excuse my stumbling forward.

[jdegre]

hi @DonRichie; thanks for reporting the issue.
from what I can see in the API definition, it seems that it is correct, and if you load the API with, say, with Swagger Editor or Swagger UI, they correctly render the response payload of the 200 OK response message, for the resource path: /{realmId}/{storageId}/records/{recordId}

the "swaps" you have done above, are not really valid, since you cannot simply replace $ref: '#/components/responses/RecordBody' with $ref: '#/components/schemas/RecordBody'

the former is a reference to an entire re-usable response component, while the latter is simply a reference to a given schema component, and both are entirely different. the reusable response component is defined as:

      content:
        multipart/mixed:
          schema:
            $ref: '#/components/schemas/Record'
          encoding:
              meta: # The meta part shall be the first part and is mandatory but can be empty.
                contentType: application/json
                headers:
                  Content-Id: # The meta part is identified by the 'meta' Content-Id header.
                    schema:
                      type: string
                    required: true
              blocks: # Zero or more block parts may follow the meta part
                contentType: '*/*' # Block parts can be of any type.
                headers:
                  Content-Id: # Block identifier is defined by the Content-Id header.
                    schema:
                      type: string
                    required: true
                  Content-Transfer-Encoding:
                    schema:
                      type: string
                    required: true
      headers:
        Cache-Control:
          $ref: '#/components/headers/Cache-Control'
        ETag:
          $ref: '#/components/headers/ETag'
        Last-Modified:
          $ref: '#/components/headers/Last-Modified'

so, it seems to me that openpi-generator does not handle well any of those definitions above.

maybe one way of narrowing-down the issue could be to replace $ref: '#/components/responses/RecordBody' in your test API, with the block I quoted above (the entire response message definition), and then, try to remove/change parts of it until you succeed with the code generation. at least this might indicate which part of such response definition is the "offending" part for openapi-generator.