[geirsagberg-udir]

Summary

ASP.NET Core 10 emits a nullable reference property in OpenAPI 3.1 as a oneOf of null and a $ref:

"customer": {
  "oneOf": [
    { "type": "null" },
    { "description": "The customer, if any.", "$ref": "#/components/schemas/Customer" }
  ]
}

ResolveOneOf only handled a single variant, so this became object?. ResolveAnyOf already handled the [type, null] pattern. Both now share one helper:

 ResolveOneOf
   if hoisted union → hoisted type
   if one variant → that variant
+  if exactly one non-null variant → that variant, nullable
   else → object

 ResolveAnyOf
   if hoisted union → hoisted type
   if one variant → that variant
-  if exactly one non-null variant (inline check) → that variant, nullable
+  if exactly one non-null variant (shared helper) → that variant, nullable
   else → object

The nullability rules in type-mapping.md now list this pattern.

Complements #150, which hoists unions with two or more non-null variants. That PR filters out null before hoisting, so [null, $ref] still reaches ResolveOneOf and becomes object there. The new test fails on #150 too.

Evidence

New test Generate_FromText_OneOfNullAndRef_GeneratesNullableReference, using the spec above:

• Before: fails — Not found: "public Customer? Customer { get; init; }" (generated public object? Customer)
  After: passes, with no OrderCustomer union hoisted, and the output compiles with warnings as errors.

dotnet test passes for the whole solution.

Merge Danger

Door: two-way

Blast Radius: generated-types

Consumers whose specs use oneOf: [null, X] get X? instead of object? when they regenerate. That is a type change in generated code, but it replaces a placeholder with the intended type. A oneOf with two or more non-null variants is unchanged.