[BUG][Go] String enum constraints are not enforced during JSON unmarshaling

[AndreyVMarkelov]

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?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The Go client generator does not enforce string property constraints declared with enum or not: { enum: [...] } when unmarshaling generated models. In particular, a model whose kind property excludes "known" accepts that value. This makes oneOf variants overlap even though the schemas are mutually exclusive.

openapi-generator version

Reproduced with a local 7.26.0-SNAPSHOT CLI before PR #25089. That PR was based on upstream commit 271e4dd6e6d. The current latest master has not been retested separately.

OpenAPI declaration file content or url

openapi: 3.1.0
info:
  title: Go not enum reproduction
  version: 1.0.0
paths: {}
components:
  schemas:
    Known:
      type: object
      required: [kind]
      properties:
        kind:
          type: string
          enum: [known]
    Other:
      type: object
      required: [kind]
      properties:
        kind:
          type: string
          not:
            enum: [known]
    TaggedUnion:
      oneOf:
        - $ref: '#/components/schemas/Known'
        - $ref: '#/components/schemas/Other'

The spec passes openapi-generator-cli validate with no validation errors. The CLI reports only recommendations that the three models are unused because the spec has no paths.

Generation Details

Generator: go, with default options.

openapi-generator-cli validate -i go-not-enum.yaml
openapi-generator-cli generate -i go-not-enum.yaml -g go -o /tmp/go-not-enum

Steps to reproduce

1. Generate the Go client from the spec above using a version before PR fix(go): validate string enum exclusions #25089.
2. Unmarshal {"kind":"known"} into the generated Other model. It is accepted (err == nil) even though Other.kind declares not: { enum: [known] }. Known also accepts {"kind":"other"} (err == nil) despite its allowed enum.
3. Unmarshal {"kind":"known"} into TaggedUnion. The generated oneOf handling returns data matches more than one schema in oneOf(TaggedUnion).

Expected behavior: Known accepts {"kind":"known"} and rejects another string value; Other rejects {"kind":"known"} and accepts {"kind":"other"}. The oneOf value should therefore match only one variant.

Validation should also preserve optional properties, nullable enum semantics, and untyped not: enum behavior. JSON property names should be matched case-insensitively, as Go encoding/json does when unmarshaling structs.

Related issues/PRs

Related Java report: #25065. Related Python report: #25069. Go fix: #25089.

Suggest a fix

Use the allowed enum and nested not enum values retained in Go codegen property metadata to generate validation before model unmarshaling. Reject excluded values while preserving the existing UnmarshalJSON paths for required and additionalProperties models.

The proposed PR includes focused generator coverage for allowed and excluded string values, nullable and optional properties, quoted values, typed and untyped not: enum, case-insensitive property names, and validating UnmarshalJSON generation. Generated Go code compiles and passes runtime checks with go test ./....