Map OpenAPI 3.1 multi-type unions to any - #2522

Greptile Summary

This PR allows valid OpenAPI 3.1 schemas with multiple declared JSON types to generate as permissive Go any values.

• Adds version-aware recognition of valid multi-type lists while preserving errors for OpenAPI 3.0 and unknown type names.
• Prevents union enums from producing invalid Go constants.
• Adds unit, integration, generated-output, and README coverage for the new mapping.

Confidence Score: 5/5

The PR appears safe to merge, with no unacknowledged actionable defects identified in the changed behavior.

The new dispatch is restricted to valid OpenAPI 3.1 multi-type lists, preserves existing malformed-input errors, and prevents enum metadata from reaching invalid constant generation.

_{Reviews (1): Last reviewed commit: "Map OpenAPI 3.1 multi-type unions to `an..." | Re-trigger Greptile}

@mromaszewicz I'd expect that we'd treat this as a oneOf in this case?

You know, I'm not sure. This isn't like oneOf because that can handle any schema definition, however, this is much more limited, because it's just top level types. I do think any, like in this PR, is a better fit. If someone wants something that is [string, array, number], it's on them to disentangle what this is. any will have the json marshaler parse this as it sees fit, while if we make it something like json.RawMessage, then the user can decide how to parse it, so to me, it's a choice between any and json.RawMessage. I'm leaning towards any.

Thanks for the PR — the core mapping is well-guarded and the writeup is unusually thorough. We ran a deep analysis with Claude on this change (probing generated output for the interaction cases against a compiled runtime), and it surfaced a few issues that make the change incomplete as-is. Findings below, roughly in order of severity.

1. Parameter positions generate code that always fails at request time

A multi-type union in a parameter now generates successfully, but the endpoint is permanently broken:

parameters:
  - name: id
    in: path
    required: true
    schema:
      type: [string, integer]

The generated handler binds into an any destination, and runtime.BindStyledParameterWithOptions / BindQueryParameter unconditionally reject that:

error binding string parameter: can not bind to destination of type: interface

So a path param typed this way 400s on every request, and a query param 400s whenever it's supplied. Before this PR the spec failed loudly at generation time; after it, the failure moves to runtime. Unlike type: "null", a string-or-integer ID is a plausible real spec, and this is the one position where any isn't merely permissive but non-functional. We'd want parameter schemas to either keep erroring at generation, or bind the raw string — not silently generate a dead endpoint.

Relatedly, the PR body says generation is exercised across "property, additionalProperties, parameter, request body, response body, array items, and allOf positions", but the committed suite only covers property, additionalProperties, a named component, and the enum interaction. If you tested the other positions locally, could you commit those tests? The parameter case above is exactly the kind of thing that coverage would have caught.

2. type list + oneOf/anyOf siblings: the composition is silently discarded

UnionWithOneOf:
  type: [string, number]
  oneOf:
    - type: string
    - type: number

generates type UnionWithOneOf = any with no union accessors, because generateUnion only runs inside the object/typeless branch of GenerateGoSchema. Not a regression (this errored before), but it's a legal 3.1 conjunction that now silently loses the As…/From… machinery a bare oneOf gets. At minimum this deserves a line in the README note.

3. allOf ordering now swallows unions silently

AllOfUnionMember:
  allOf:
    - properties:
        name:
          type: string
    - type: [string, number]

generates a plain struct — the union member's type vanishes, because MergeSchemas does result.Type = s1.Type and discards s2's type when s1 has none. Reverse the member order and you get any with the properties dropped instead. The order-dependency is a pre-existing MergeSchemas bug (single types behave the same on main), so it's not this PR's fault — but the PR converts some of these from hard errors into silent, order-dependent output. Worth either a guard or a tracking issue.

Confirmed as fine

• The strict-server any-response compile failure reproduces on main with schema: {}, exactly as the PR body says — pre-existing, not introduced here.
• Nullability handling is correct throughout: [string, number, "null"] properties render bare any without omitempty, and nullable.Nullable[any] under the nullable-type option.
• The enum guard is correctly placed, the 3.0/typo rejection works as described, and x-go-type still wins as an escape hatch since extensions are handled before type dispatch.
• A union as a oneOf branch works (accessor typed any), with the caveat that As… can never fail, so branch discrimination degrades — same as typeless branches today.

Overall: the schema-position mapping looks merge-worthy, but we'd like the parameter story resolved (and the position tests committed) before this lands.