[BUG][core] Normalize OAS 3.1 type: null map value (additionalProperties) under NORMALIZE_31SPEC

[seonwooj0810]

Fixes #23945

Problem

With --openapi-normalizer NORMALIZE_31SPEC=true, a nullable map whose additionalProperties value schema still contains JSON Schema null was not normalized to a usable OAS 3.0 value type. Generators emitted a fictional Null / ModelNull value type that fails to compile, e.g. Map<String, ModelNull> (Java) with no ModelNull model generated, Dictionary<string, Null> (csharp, CS0246), etc.

Two value-schema shapes from the report:

stringMap:
  type: [object, "null"]
  additionalProperties:
    type: "null"
errorsByKey:
  type: [object, "null"]
  additionalProperties:
    type: [array, "null"]
    items: { ... }

Root cause

In OpenAPINormalizer#normalizeSchema, the map branch recurses into additionalProperties but:

1. A pure type: "null" value schema is short-circuited by ModelUtils.isNullTypeSchema(...) at the top of normalizeSchema and returned unchanged, so it keeps its OAS 3.1 null type.
2. A type: [array, "null"] value schema is converted by processNormalize31Spec into a new ArraySchema, but the map branch discarded the return value (normalizeSchema(...) was called without reassigning additionalProperties), leaving the value half-converted.

This is the remaining gap after #22056 (which covered additionalProperties: false on closed objects, not nullable map values).

Fix

In the map branch, when NORMALIZE_31SPEC is enabled:

• rewrite a pure-null additionalProperties value to an any-type nullable schema, so the map value generates as a normal (nullable) object; and
• capture the normalized value schema for the other cases (so the [array, "null"] rewrite is not lost).

The change is fully gated behind NORMALIZE_31SPEC; behavior is unchanged when the rule is off. No committed sample config uses NORMALIZE_31SPEC, so no generated samples change.

Test evidence

Added OpenAPINormalizerTest#testOpenAPINormalizer31SpecNullMapAdditionalProperties (spec src/test/resources/3_1/issue_23945.yaml) asserting the stringMap value loses its null type (becomes any-type nullable) and the errorsByKey value becomes a nullable array.

mvn -pl modules/openapi-generator test -Dtest=OpenAPINormalizerTest
Tests run: 61, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

Verification done: (1) confirmed no in-flight PR (gh pr list search for NORMALIZE_31SPEC/23945 returned none); (2) no self-claim — issue has 0 comments; (3) code-only change to .java + test; (4) reproduced the bug on master with a failing assertion before the fix (stringMap value stayed types=[null], errorsByKey value stayed type=null/types=[array]); (5) full OpenAPINormalizerTest (61 tests) green.

🤖 Generated with Claude Code

---

Summary by cubic

Fixes normalization of nullable map values in OAS 3.1 under NORMALIZE_31SPEC so generators no longer emit fictional Null/ModelNull types and maps compile correctly.

• Bug Fixes
  • In OpenAPINormalizer#normalizeSchema, when additionalProperties is type: "null", rewrite to an any-type nullable schema.
  • Capture and reassign the normalized value schema for cases like type: [array, "null"] so it becomes a nullable array.
  • All changes gated behind NORMALIZE_31SPEC; default behavior unchanged.
  • Added OpenAPINormalizerTest#testOpenAPINormalizer31SpecNullMapAdditionalProperties and 3_1/issue_23945.yaml to cover both shapes.

^{Written for commit ed90132. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}