Fix JsonSchemaExporter dropping nullability for nullable floating-point composition schemas

[Copilot]

JsonSchemaExporter omitted null-acceptance for CLR-nullable types (double?, float?, Half?) whose schema is emitted as an anyOf composition — which happens for IEEE floating-point types under JsonNumberHandling.AllowNamedFloatingPointLiterals. The same property exports correctly as {"type":["number","null"]} under default number handling, so a double? was advertised to downstream JSON-Schema/OpenAPI consumers as a non-nullable number.

Description

• Root cause — JsonSchema.MakeNullable only adds JsonSchemaType.Null when the schema carries a concrete type keyword. Composition schemas (anyOf) have Type == Any, so nullable wrappers over floating-point anyOf schemas could lose nullability.
• Fix — Introduced a new internal virtual bool IsIeeeFloatingPointConverter property on JsonConverter, overridden to true in DoubleConverter, SingleConverter, and HalfConverter. Updated the nullable-value-type path in JsonSchemaExporter.MapJsonSchemaCore to check this property instead of performing brittle element type checks: when the element schema is anyOf and the converter is an IEEE floating-point converter, null is folded into the numeric branch's type keyword ("type": ["number","null"]). For non-IEEE converters (e.g., nullable struct unions), a standalone { "type": "null" } branch is appended to ensure nullability. Added a Debug.Assert to validate the expected shape for IEEE floating-point types with AllowNamedFloatingPointLiterals.
• Tests — Added regression coverage for double?, float?, Half?, and a POCO with nullable floating-point properties under global AllowNamedFloatingPointLiterals, plus nullable struct union test cases, across reflection and source-gen test contexts.

Resulting export for a nullable property:

// double? under AllowNamedFloatingPointLiterals
{"anyOf":[{"type":["number","null"]},{"enum":["NaN","Infinity","-Infinity"]}]}

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json
See info in area-owners.md if you want to be subscribed.

[eiriktsarpalis]

@copilot This doesn't look right.

[eiriktsarpalis]

This looks invalid. The expected schema should have had the first subschema be { "type" : ["number","null"] }.

[Copilot]

Updated — the first subschema is now { "type": ["number","null"] } and the separate null branch is gone. Fixed in 11a4bcb.

[Copilot]

@copilot This doesn't look right.

Agreed — the original approach was wrong. I've reworked it in 3279084a: instead of appending a standalone { "type": "null" } branch to the anyOf, MakeNullable now folds null into the first branch that carries a concrete type. So a double? under AllowNamedFloatingPointLiterals now exports as:

{"anyOf":[{"type":["number","null"]},{"enum":["NaN","Infinity","-Infinity"]}]}

This also handles the empty/type-less anyOf edge case (no spurious null branch) and skips branches that already permit null. The test expectations were corrected accordingly. (Note: my two earlier thread replies referenced an incorrect short hash; the correct commit is 3279084a.)

[eiriktsarpalis]

@copilot I fail to see how this fix is valid in the general case. If anyOf contained objects, this code would erroneously insert null in the first object in the list which we clearly don't want to do. What we should be fixing here is handling specifically for nullable structs when number handling is specified, not inaccurate post hoc patching like is being attempted here.

[Copilot]

You're right. I reverted the MakeNullable change entirely and moved the fix into the nullable-value-type path (NullableElementConverter block in JsonSchemaExporter), alongside the existing enum handling. This code only runs for Nullable<T>, where the element schema can only be an anyOf when it's an IEEE floating-point type under AllowNamedFloatingPointLiterals — so the null is folded into the numeric branch ({ "type": ["number","null"] }) and never touches object/polymorphic compositions. Fixed in c81c58a.

[Copilot]

Pull request overview

Fixes JSON Schema export for nullable IEEE floating-point types when JsonNumberHandling.AllowNamedFloatingPointLiterals causes the element schema to be expressed as an anyOf composition, ensuring null remains an accepted value in the exported schema.

Changes:

• Update JsonSchemaExporter.MapJsonSchemaCore to preserve null acceptance for nullable-wrapper schemas when the element schema is an anyOf with an enum branch (named float literals).
• Add regression coverage for double?, float?, and a POCO with nullable floating-point properties under global AllowNamedFloatingPointLiterals.
• Extend the source-generation test context to include the new nullable float and POCO test types.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/libraries/System.Text.Json/src/System/Text/Json/Schema/JsonSchemaExporter.cs	Adds nullable-wrapper handling for anyOf schemas by appending null to the relevant enum branch.
src/libraries/System.Text.Json/tests/Common/JsonSchemaExporterTests.TestTypes.cs	Adds regression test vectors for nullable floating-point schemas under AllowNamedFloatingPointLiterals.
src/libraries/System.Text.Json/tests/System.Text.Json.SourceGeneration.Tests/Serialization/JsonSchemaExporterTests.cs	Updates the source-gen context to include the new test types.

[tarekgh]

A few issues found while reviewing the nullable floating-point fix.

[tarekgh]

This emits {"enum":["NaN","Infinity","-Infinity",null]}. For consistency with the default number-handling output ({"type":["number","null"]}), null should be folded into the type keyword of the numeric branch instead, producing {"anyOf":[{"type":["number","null"]},{"enum":["NaN","Infinity","-Infinity"]}]}.

[tarekgh]

If no branch carries an Enum, the loop completes without adding null and the schema is silently left non-nullable. Recommend a Debug.Assert that elementTypeInfo is a numeric type formatted with AllowNamedFloatingPointLiterals, plus a safe fallback so null is still accepted if the element shape ever changes.

[tarekgh]

This comment is too absolute. NullableElementConverter is also used by other internal wrappers (F# option/value-option, casting converters), so an anyOf here is not provably only an IEEE float schema. Soften the wording and pair it with the assert/fallback noted below.

[tarekgh]

Left a few comments, LGTM otherwise.

[eiriktsarpalis]

@copilot

[eiriktsarpalis]

@copilot This check is too brittle and could possibly break with things like nullable C# struct unions. (Do we have tests for these? if not please add a few here!)

What I would recommend instead is introducing a new internal virtual bool IsIeeeFloatingPointConverter => false property on JsonConverter and have that overridden on the relevant built-in converters (assuming such a flag doesn't exist already). This branch should only be entered by checking against that property on elementConverter.

[Copilot]

Introduced a new internal virtual bool IsIeeeFloatingPointConverter => false property on JsonConverter, overridden to true in DoubleConverter, SingleConverter, and HalfConverter. The nullable-wrapper path now checks elementConverter.IsIeeeFloatingPointConverter before folding null into the numeric branch. For non-IEEE converters (e.g., nullable struct unions), the code appends a standalone { "type": "null" } branch to preserve nullability. Added test coverage for nullable struct unions. Fixed in a272333.

[eiriktsarpalis]

@copilot replace the redundant boolean with a debug assert that calls List.Exists before the foreach.

[Copilot]

Replaced the boolean with a Debug.Assert(anyOf.Exists(b => (b.Type & JsonSchemaType.Number) != 0)) before the foreach loop. Fixed in a272333.