-
Notifications
You must be signed in to change notification settings - Fork 299
Handle OpenAPI schemas with format but no type keyword #7330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: gavinbarron <7122716+gavinbarron@users.noreply.github.com>
…ectly Co-authored-by: gavinbarron <7122716+gavinbarron@users.noreply.github.com>
|
@copilot please expand this fix given that the type property is optional we could see format uuid without the type for example. I expect that the format checks happen independent of the type checks, only using the type field as a fallback if no format has bee supplied |
Co-authored-by: gavinbarron <7122716+gavinbarron@users.noreply.github.com>
Co-authored-by: gavinbarron <7122716+gavinbarron@users.noreply.github.com>
Expanded the fix in commit b863256. All format checks now happen independently of type, with type serving only as a fallback when format is absent or unrecognized. This includes uuid, base64url, and all numeric formats (int8, uint8, int16, int32, int64, double, float, decimal). Added 20 new test cases covering all supported formats without type. |
…tterns Co-authored-by: gavinbarron <7122716+gavinbarron@users.noreply.github.com>
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
Additionally, can you please add a changelog entry. |
|
@copilot please add a changelog entry for this fix |
Co-authored-by: gavinbarron <7122716+gavinbarron@users.noreply.github.com>
baywet
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for making the changes!
|
@adrian05-ms to give it another review, since I handled conflicts, I can't give it the final review. |
_patterns to explicit type matching withor null(JsonSchemaType.String or null, "format")(JsonSchemaType.Number or JsonSchemaType.Integer or null, "format")Original prompt
This section details on the original issue you should resolve
<issue_title>Deal with missing
typekeyword</issue_title><issue_description>### 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
The OpenApi generator from Asp.NET started omitting the
typekeyword forDateTimeproperties starting with .NET 10:"createdAt": { -"type": "string", "format": "date-time" }This results in
UntypedNodebeing generated. This is legal according to the OAI spec and means "accept any object as long as it behaves like a date-time".Expected behavior
We should probably default to
stringin that case.How to reproduce
A schema like this:
Open API description file
No response
Kiota Version
1.29.0
Latest Kiota version known to work for scenario above?(Not required)
No response
Known Workarounds
No response
Configuration
No response
Debug output
Click to expand log
```To accomplish this change I propose we drop the schemaType match and move it down the list so that it doesn't apply to numbers, integers, or booleans.
The next natural question; has the same thing happened for formats of
time,date, orduration?If so, we might end up with something like: