microsoft
Error when creating client for c# type int
What are you generating using Kiota, clients or plugins?
API Client/SDK
In what context or format are you using Kiota?
Nuget tool
Client library/SDK language
Csharp
Describe the bug
I have this simple model:
public class Image
{
[JsonPropertyName("imageId")]
public string? ImageId { get; set; }
[JsonPropertyName("url")]
public string? Url { get; set; }
// Cambiado a Dictionary
[JsonPropertyName("altText")]
public Dictionary<string, string>? AltText { get; set; }
[JsonPropertyName("width")]
public int Width { get; set; }
[JsonPropertyName("height")]
public int Height { get; set; }
}
As you can see, at the bottom there are two properties with type int. My c# OpenApi generator creates this spec:
// not relevant content
"components": {
"schemas": {
"Image": {
"type": "object",
"properties": {
"imageId": {
"type": [
"null",
"string"
]
},
"url": {
"type": [
"null",
"string"
]
},
"altText": {
"type": [
"null",
"object"
],
"additionalProperties": {
"type": "string"
}
},
"width": {
"pattern": "^-?(?:0|[1-9]\\d*)$",
"type": [
"integer",
"string"
],
"format": "int32"
},
"height": {
"pattern": "^-?(?:0|[1-9]\\d*)$",
"type": [
"integer",
"string"
],
"format": "int32"
}
}
},
// ....
Width and height is being created with two types (integer and string) (as I suppose you can do "23" and parse as string).
But when I try to create a client for my C# Razor pages, 1.26.0 kiota generates this warning:
warn: Kiota.Builder.KiotaBuilder[0]
OpenAPI warning: #/components/schemas/Image/properties/width - The format int32 is not supported by Kiota for the type Integer, String and the string type will be used.
warn: Kiota.Builder.KiotaBuilder[0]
OpenAPI warning: #/components/schemas/Image/properties/height - The format int32 is not supported by Kiota for the type Integer, String and the string type will be used.
This is correct? For now, my solution is to use OpenAPI v3.0, so I don't get multitypes and Kiota doesn't warn about that.
Expected behavior
Kiota should allow multi type schemas
How to reproduce
model is in the description of the issue
kiota generate -d https://localhost:7241/openapi/v1.json -l CSharp -c ApiClientClass -n ReaderApi.Client -o ./ApiClient --exclude-backward-compatible --clean-output
Open API description file
No response
Kiota Version
1.26.0+dd06afb176dd502bb75cefa5c024d7347263b53c
Latest Kiota version known to work for scenario above?(Not required)
No response
Known Workarounds
Use OpenAPI v3.0, so I don't get multitypes and Kiota doesn't warn about that.
Configuration
Windows 11
Debug output
Click to expand log
```info: Kiota.Builder.KiotaBuilder[0] Cleaning output directory C:\Users\XXX\CosasGit\ProyectosGit\XXXX\ReaderApi.Client.\ApiClient dbug: Kiota.Builder.KiotaBuilder[0] kiota version 1.26.0 dbug: Kiota.Builder.KiotaBuilder[0] cache file C:\Users\XXX\AppData\Local\Temp\kiota\cache\generation\E7BA93B18316176A90FF66F0D4DC0AF7359BA4EFE54C6E6D8C244D909E4490C7\v1.json not found, downloading from https://localhost:7241/openapi/v1.json info: Kiota.Builder.KiotaBuilder[0] skipping cache write for URI https://localhost:7241/openapi/v1.json as it is a loopback address info: Kiota.Builder.KiotaBuilder[0] loaded description from remote source dbug: Kiota.Builder.KiotaBuilder[0] step 1 - reading the stream - took 00:00:00.1480758 warn: Kiota.Builder.KiotaBuilder[0] OpenAPI warning: #/components/schemas/Image/properties/width - The format int32 is not supported by Kiota for the type Integer, String and the string type will be used. warn: Kiota.Builder.KiotaBuilder[0] OpenAPI warning: #/components/schemas/Image/properties/height - The format int32 is not supported by Kiota for the type Integer, String and the string type will be used. warn: Kiota.Builder.KiotaBuilder[0] OpenAPI warning: #/components/schemas/ProblemDetails/properties/status - The format int32 is not supported by Kiota for the type Integer, String and the string type will be used. dbug: Kiota.Builder.KiotaBuilder[0] step 2 - parsing the document - took 00:00:00.0963585 dbug: Kiota.Builder.KiotaBuilder[0] step 3 - updating generation configuration from kiota extension - took 00:00:00.0001215 dbug: Kiota.Builder.KiotaBuilder[0] step 4 - filtering API paths with patterns - took 00:00:00.0048840 info: Kiota.Builder.KiotaBuilder[0] Client root URL set to https://localhost:7241 dbug: Kiota.Builder.KiotaBuilder[0] step 5 - checking whether the output should be updated - took 00:00:00.0214610 dbug: Kiota.Builder.KiotaBuilder[0] step 6 - create uri space - took 00:00:00.0038184 dbug: Kiota.Builder.KiotaBuilder[0] InitializeInheritanceIndex 00:00:00.0042083 dbug: Kiota.Builder.KiotaBuilder[0] CreateRequestBuilderClass 00:00:00 dbug: Kiota.Builder.KiotaBuilder[0] MapTypeDefinitions 00:00:00.0070214 dbug: Kiota.Builder.KiotaBuilder[0] TrimInheritedModels 00:00:00 dbug: Kiota.Builder.KiotaBuilder[0] CleanUpInternalState 00:00:00 dbug: Kiota.Builder.KiotaBuilder[0] step 7 - create source model - took 00:00:00.0778695 dbug: Kiota.Builder.KiotaBuilder[0] 34ms: Language refinement applied dbug: Kiota.Builder.KiotaBuilder[0] step 8 - refine by language - took 00:00:00.0347924 dbug: Kiota.Builder.KiotaBuilder[0] step 9 - writing files - took 00:00:00.0893534 dbug: Kiota.Builder.KiotaBuilder[0] cache file C:\Users\XXX\AppData\Local\Temp\kiota\cache\generation\E7BA93B18316176A90FF66F0D4DC0AF7359BA4EFE54C6E6D8C244D909E4490C7\v1.json not found, downloading from https://localhost:7241/openapi/v1.json info: Kiota.Builder.KiotaBuilder[0] skipping cache write for URI https://localhost:7241/openapi/v1.json as it is a loopback address info: Kiota.Builder.KiotaBuilder[0] loaded description from remote source dbug: Kiota.Builder.KiotaBuilder[0] step 10 - writing lock file - took 00:00:00.0255176 Generation completed successfully Client base url set to https://localhost:7241 dbug: Kiota.Builder.KiotaBuilder[0] Api manifest path: C:\Users\XXX\CosasGit\ProyectosGit\XXXX\ReaderApi.Client\apimanifest.json
</details>
### Other information
_No response_
Hi @rodriciru , Thank you for using kiota and for reaching out.
What do you use to generate the OpenAPI specification from your model? The Asp.net OpenAPI integration? something else?
Yes, asp openAPI As I understand, openAPI 3.1 allow multiple types,but not 3.0 or lower.
So kiota, should allow this when using 3.1 I'm right?
yes, however this is effectively a union type. I'm not sure it'll be super practical, especially with the format being specified.
@captainsafia maybe something we'd want to review on the document generation side?
@baywet This is the scheme that STJ produces by default based on its parsing semantics. By default, STJ in .NET will parse strings in the number format and numbers as int when deserializing JSON. To make this behavior stricter, it is necessary to configure this option to restrict number handling to just integers. When this is done, the schema will not return the union type.
Great. But if open API 3.1 allow this, kiota should allow this as well no?
@captainsafia I believe it'd make more sense to emit numbers... as numbers only. The "string hack" was so parsers would not overflow on large numbers. But any modern parser should guard against that.
@rodriciru what's your main concern here? the warning? or the fact that properties get emitted as a union type?
I think if 3.1 allow union types kiota should respect that. But I'm the mid time , serialised as only int will be good
El lun, 30 jun 2025, 16:19, Vincent Biret @.***> escribió:
baywet left a comment (microsoft/kiota#6541) https://github.com/microsoft/kiota/issues/6541#issuecomment-3019349254
@captainsafia https://github.com/captainsafia I believe it'd make more sense to emit numbers... as numbers only. The "string hack" was so parsers would not overflow on large numbers. But any modern parser should guard against that.
@rodriciru https://github.com/rodriciru what's your main concern here? the warning? or the fact that properties get emitted as a union type?
— Reply to this email directly, view it on GitHub https://github.com/microsoft/kiota/issues/6541#issuecomment-3019349254, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACR6MYZ73MVVOQBKTUNVJM33GFBPLAVCNFSM6AAAAAB4WIUNVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJZGM2DSMRVGQ . You are receiving this because you were mentioned.Message ID: @.***>
This method most likely needs to be updated to account for the flaggable enum now:
https://github.com/microsoft/kiota/blob/66acc176b3efeb437e41e07784a1b775f254e5b3/src/Kiota.Builder/KiotaBuilder.cs#L1828
Is this something you'd like to submit a pull request for provided some guidance?
Sorry, but my personal life, work and c# skills makes me Impossible to make a PR.
Really sorry guys
El mié, 2 jul 2025, 19:50, Vincent Biret @.***> escribió:
baywet left a comment (microsoft/kiota#6541) https://github.com/microsoft/kiota/issues/6541#issuecomment-3028799084
This method most likely needs to be updated to account for the flaggable enum now:
https://github.com/microsoft/kiota/blob/66acc176b3efeb437e41e07784a1b775f254e5b3/src/Kiota.Builder/KiotaBuilder.cs#L1828
Is this something you'd like to submit a pull request for provided some guidance?
— Reply to this email directly, view it on GitHub https://github.com/microsoft/kiota/issues/6541#issuecomment-3028799084, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACR6MY6XTA3BTXGWBSLYTBD3GQLVVAVCNFSM6AAAAAB4WIUNVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMRYG44TSMBYGQ . You are receiving this because you were mentioned.Message ID: @.***>
@baywet This is the scheme that STJ produces by default based on its parsing semantics. By default, STJ in .NET will parse strings in the number format and numbers as
intwhen deserializing JSON. To make this behavior stricter, it is necessary to configure this option to restrict number handling to just integers. When this is done, the schema will not return the union type.
Ran into this issue and this fix worked:
builder.Services.Configure<JsonOptions>(o => o.SerializerOptions.NumberHandling = JsonNumberHandling.Strict);
It would be nice if no changes were needed however. Either ASPNET should be changed to use Strict by default, or kiota should be adapted to handle this properly.
