René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"MergeSchemas silently drops a member's type when an earlier allOf member has none (order-dependent output)","articleBody":"Found during the review of #2522; pre-existing on `main` and independent of that PR.\n\n## Problem\n\n`MergeSchemas` (pkg/codegen/merge_schemas.go) only errors on a type conflict when **both** members declare a type:\n\n```go\nif s1.Type.Slice() != nil && s2.Type.Slice() != nil && !equalTypes(s1.Type, s2.Type) {\n    return openapi3.Schema{}, fmt.Errorf(\"can not merge incompatible types: ...\")\n}\nresult.Type = s1.Type\n```\n\nWhen `s1` has no type and `s2` does, `result.Type = s1.Type` silently discards `s2`'s type. Because allOf members are merged pairwise in order, the generated Go shape depends on member ordering.\n\n## Reproduction\n\n```yaml\nAllOfUnionMember:\n  allOf:\n    - properties:\n        name:\n          type: string\n    - type: [string, number]\n```\n\ngenerates a plain struct — the second member's type constraint vanishes entirely:\n\n```go\ntype AllOfUnionMember struct {\n    Name *string `json:\"name,omitempty\"`\n}\n```\n\nReversing the member order flips which constraint silently wins: `result.Type` then carries the union, the schema lowers to `any`, and the `properties` are dropped instead. The same mechanism applies to single types (`- type: string` as the second member is discarded the same way); the multi-type union case from #2521/#2522 just made it easier to notice, and converted some of these from hard generation errors into silent, order-dependent output.\n\n## Expected\n\nOrder should not change the result. Either:\n\n- propagate the type when exactly one member declares one (`result.Type = firstNonNil(s1.Type, s2.Type)`), keeping the existing incompatibility error when both declare different types, or\n- error loudly on the typeless+typed combination if propagation has unwanted interactions (e.g. a propagated primitive type alongside merged properties still silently drops the properties at the dispatch stage — propagation alone doesn't make that combination coherent).\n\nThe first option fixes the common case (a typeless member contributing only `properties`/`required` alongside a typed member); the second at least removes the silent order dependency. Behavior change to generated code either way, so this likely wants a look at what existing specs in the wild rely on before choosing.\n","author":{"url":"https://github.com/mromaszewicz","@type":"Person","name":"mromaszewicz"},"datePublished":"2026-08-16T14:27:28Z","url":"https://github.com/oapi-codegen/oapi-codegen/issues/2524"}