fix: map numeric scalar unions with a format to the numeric type

[FabienDehopre]

Fixes #6541

The problem

ASP.NET Core's OpenAPI 3.1 generator emits numeric members as a scalar union under System.Text.Json's default JsonNumberHandling.AllowReadingFromString:

"temperatureC": {
  "pattern": "^-?(?:0|[1-9]\\d*)$",
  "type": ["integer", "string"],
  "format": "int32"
}

KiotaBuilder.GetPrimitiveType computes the combined JsonSchemaType flags (Integer | String), which none of the switch arms match, so it returns null and the property degrades to UntypedNode — making these properties effectively unusable in the generated client. Since this is the out-of-the-box output of .NET 10's OpenAPI document generation, any ASP.NET Core API documented with the built-in generator hits this.

The fix

In GetPrimitiveType, when the schema type combines String with Integer or Number, strip the String flag before matching, so the numeric type (honoring format) wins. This follows the direction suggested in #6541 (comment): emit numbers as numbers only.

Scope is deliberately narrow:

• Scalar unions without a format are untouched: they never reach this code path for model properties (IsExclusiveUnion() routes them to CreateComposedModelDeclaration, which generates the composed type wrapper as before). A test asserts this behavior is preserved.
• Unions not involving a numeric type (["string", "boolean"], object unions, …) are untouched.
• The fix is in the builder, so all target languages benefit.

Tests

• New theory covering ["integer","string"] / ["number","string"] with int32, int64, double, float, and the nullable variants (Null flag), asserting the numeric type is generated.
• Two cases asserting the no-format composed-type behavior is unchanged.
• Full Kiota.Builder.Tests suite passes (2198 passed, 0 failed).
• Verified end-to-end: regenerating a client from the exact document in Error when creating client for c# type int #6541's scenario now produces public int? TemperatureC { get; set; } instead of UntypedNode.

🤖 Generated with Claude Code

[FabienDehopre]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

This PR updates Kiota’s schema-to-primitive mapping so OpenAPI 3.1 numeric “scalar unions” emitted by ASP.NET Core (e.g. type: ["integer","string"] with format: int32) resolve to numeric primitives instead of degrading to UntypedNode, improving usability of generated SDK models.

Changes:

• Adjust KiotaBuilder.GetPrimitiveType to prefer numeric types over string when schema types combine numeric + string.
• Add builder tests covering numeric/string unions with formats (and asserting existing no-format composed-type behavior for model properties).
• Document the behavior change in CHANGELOG.md.

Reviewed changes

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

File	Description
src/Kiota.Builder/KiotaBuilder.cs	Updates primitive type resolution logic for numeric+string scalar unions.
tests/Kiota.Builder.Tests/KiotaBuilderTests.cs	Adds regression tests for numeric/string scalar unions (format and no-format cases).
CHANGELOG.md	Notes the updated mapping behavior for numeric scalar unions with formats.

[baywet]

Thanks for the contribution!

[baywet]

@FabienDehopre can you also apply the copilot suggestions please?

[FabienDehopre]

Both copilot suggestions have been applied.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[baywet]

Thank you for making the changes!

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/Kiota.Builder/Validation/InconsistentTypeFormatPair.cs:59

• InconsistentTypeFormatPair warning text still says “the string type will be used”, but after the sanitizedType adjustment (and KiotaBuilder.GetPrimitiveType’s default numeric fallbacks), numeric|string unions with an unsupported format will map to a numeric type (e.g., Integer → integer) rather than string. This makes the warning misleading for the scenario this rule now targets.

            context.CreateWarning(nameof(InconsistentTypeFormatPair), $"The format {schema.Format} is not supported by Kiota for the type {sanitizedType} and the string type will be used.");

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[FabienDehopre]

@baywet I did push some more commits to comply to all the remaining copilot suggestions.
I think you need to re-approve the PR. Also, what's the next step before it gets merged? I see that some checks are failing (the idempotency tests) but it seems not related to this PR.