[BUG] [Go-server] invalid composite literal type string

[Tomer-L]

Bug Report Checklist

• [x] Have you provided a full/minimal spec to reproduce the issue?
• [x] Have you validated the input using an OpenAPI validator (example)?
• [x] Have you tested with the latest master to confirm the issue still exists?
• [x] Have you searched for related issues/PRs?
• [x] What's the actual output vs expected output?
• [ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Generating the following yaml spec you will get code that does not compile with the following errors:

Error 1: invalid composite literal type string

api_test_api.go on line 63

bodyParam := string{}

Expected code ->

bodyParam := ""

Error 2: "github.com/gorilla/mux" imported and not used

Second compilation error is on file api_test_api.go line 17 There are at least 3 open issues: #8847 #5153 #11097

openapi-generator version

latest stable 7.1.0

OpenAPI declaration file content or url

openapi: 3.1.0
info:
  title: test
  description: API specification
  version: 1.0.0
servers:
  - url: /api/v1
paths:
  /collection/test:
    post:
      summary: POST a test batch
      operationId: postTest
      tags:
        - test api
      requestBody:
        $ref: '#/components/requestBodies/TestBody'
      responses:
        '200':
          $ref: '#/components/responses/SuccessfulOp'

components:
  responses:
    SuccessfulOp:
      description: Successful Operation
      content:
        application/json:
          schema:
            type: bool

  requestBodies:
    TestBody:
      description: Test body
      required: true
      content:
        text/plain:
          schema:
            type: string
            format: byte

Generation Details

I used the following command:

java -jar  generate --additional-properties=packageName=test,sourceFolder=test -i collection_test.yaml -g go-server

Steps to reproduce

1. copy yaml content into a new file
2. generate using -i file_name.yaml -g go-server

Related issues/PRs

Could not find issues related to "invalid composite literal type string" error

Suggest a fix

[kfircohen123]

Encountered this issue as well...

[wing328]

tested with the spec again and looks like the issue has been resolved

please give it a try with the latest master

friendly reminder: OpenAPI 3.1 support is still beta

[merterpam]

Is this issue really resolved?

We face the same problem and I tried to test it with the latest master, but I still have the following line generated:

bodyParam := string{}

and the Invalid composite literal type error.

From what I see, this comes from controller-api.mustache on line 594

{{paramName}}Param := {{dataType}}{}

I don't really know how Mustache works, but I think there needs to be a special handling of literal types for body parameters?

[wing328]

what about using {{#isPrimitveType}} ... {{/isPrimitiveType}} check ?

[vingarzan]

The bug seems to be still in the master branch.

I'm super new, but would maybe this replacement line work better?

var {{paramName}}Param {{dataType}}

This should be equivalent with the := initialization, yet we won't have to deal with a moustache "if" for checking if dataType is a Go "composite" data type.

Did a PR here https://github.com/OpenAPITools/openapi-generator/pull/20467

[vingarzan]

Since templates are user-replaceable, as temp solution until that PR is accepted/merged/released/etc is to read this https://openapi-generator.tech/docs/templating and then

1. extract the templates

openapi-generator-cli author template -g go-server

2. patch controller-api.mustache like I did in the PR

-	{{paramName}}Param := {{dataType}}{}
+	var {{paramName}}Param {{dataType}}

3. generate with the custom templates using the -t directory-where-templates-are option

[wing328]

thanks for the fix by https://github.com/OpenAPITools/openapi-generator/pull/20467, which has been merged.

please give it a try with the latest master: https://github.com/OpenAPITools/openapi-generator/wiki/FAQ#how-to-test-with-the-latest-master-of-openapi-generator

[vingarzan]

@wing328 Many many thanks for your help! I will definitely come back and help in the future!

I tested with the last master and it works as expected.