[BUG] [GO] Client does not allow unknown fields in response meaning additions to APIs break clients

[acabarbaye]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• 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?
  make the json serialisation of responses more permissive
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

wherever deserialisation is performed, option DisallowUnknownFields is set

openapi-generator/modules/openapi-generator/src/main/resources/go-server/controller-api.mustache

Line 616 in 5eb083e

d.DisallowUnknownFields()

. This means that if an API is being extended on a server and fields are added. Although this should not be a breaking change, this leads to all clients failing parsing server responses.

Suggest a fix

Either add an option to be strict or not about the schema or be more permissive and remove the DisallowUnknownFields when parsing responses

[ctreatma]

I suspect this is related to #21169. What value are you specifying for disallowAdditionalPropertiesIfNotPresent? The default value for that config option, true, means that generated code will block additional properties by default, which is the opposite of the OpenAPI standard.

[acabarbaye]

Hi @ctreatma
I think you are correct and your suggestion should most likely fix my problem too. However, I think the logic in the template is still misleading as it links it to the concept of additionalProperties via isAdditionalPropertiesTrue. My understanding (https://www.apimatic.io/openapi/additionalproperties) is really for being able to pass arbitrary data which we do not really want to specify but which we expect still to be used by either the client or the service. However, in this case, this prevents any addition to an API, which makes me wonder how people manage to cope with API changes in general. What I am trying to say is that I don't really see when people would ever want the client to not ignore additional fields it is not aware of. if there is such use cases, I would make it explicit in the template with a "strictSchema" option or something rather than piggyback on another concept (additionalProperties)