[BUG][Golang][client] README.md example wrong return value

[bkabrda]

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?
• [Optional] Bounty to sponsor the fix (example)

Description

All my operations are generated with a return signature that is a 3-tuple, for example:

func (a *UserApiService) Create(ctx context.Context, userCreatePayload UserCreatePayload) (UserCreateResponse, *http.Response, error) {

README.md however lists this as an example:

r, err := client.Service.Operation(auth, args)

This is wrong as it suggests that the return value is a 2-tuple.

openapi-generator version

Happens both in 4.0.0-beta3 and 3.3.4

OpenAPI declaration file content or url

I'm honestly not sure how to find a reproducer for this. It happens with openapi-generator installed through npm, but I can't reproduce it on the petstore example, where the generated operations really do seem to return 2-tuples.

The template go/api.mustache does have this:

func (a *{{{classname}}}Service) {{{nickname}}}(ctx context.Context{{#hasParams}}, {{/hasParams}}{{#allParams}}{{#required}}{{paramName}} {{{dataType}}}{{#hasMore}}, {{/hasMore}}{{/required}}{{/allParams}}{{#hasOptionalParams}}localVarOptionals *{{{nickname}}}Opts{{/hasOptionalParams}}) ({{#returnType}}{{{returnType}}}, {{/returnType}}*http.Response, error) {

which suggests that the first return value only gets rendered if {{returnType}} is defined, but the README doesn't take this into account. However I'm not sure where this value comes from and why I can't reproduce on the petstore example.

Command line used for generation

openapi-generator generate -g go -c config/languages/go.json -i spec/full_spec.yaml -o generated/myclient

Steps to reproduce

For me, the reproducer is just running the above command.

Related issues/PRs

I haven't found any.

Suggest a fix

I think that taking the {{returnValue}} variable into account in the README example should fix this.

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[wing328]

I think that taking the {{returnValue}} variable into account in the README example should fix this.

Thanks for reporting the issue. Please file a PR so that we can review the fix more easily.

[bkabrda]

So I've done some more digging and unfortunately it's more complicated than that.

IIUC the {{returnType}} value is set per-operation in DefaultCodegen.fromOperation and is only set when responseSchema for that operation is set. That's why I'm getting the 3-tuples as return values (I have these defined everywhere) and the petstore example doesn't get these everywhere (it only has response schemas defined on some operations). This means that depending on the spec, this can vary throughout the generated codebase and can be mixture of both inside one generated client.

I'm not 100 % sure what would be the best course of action here. If backwards compatibility is to be preserved, we have to always work with the possibility of having both 3-tuples and 2-tuples returned in any given client. Hence the README.md should probably be modified to reflect that this is operation dependent and the user should refer to the specific operation documentation. Does this make sense?