-
Notifications
You must be signed in to change notification settings - Fork 214
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
Multiple identical classes are generated for a component schema with allOf inheritance #4191
Comments
Thanks for raising this @bkoelman I believe the issue is that second endpoint (paths./api/todoItems/{id}.get) uses an inline schema for its response type with https://learn.microsoft.com/en-us/openapi/kiota/models#components-versus-inline-models As the allOf is only of one type, any chance you get a different result if you modify the description to directly reference the |
Thanks for investigating. If I patch the OAS manually as you suggested, the problem goes away. We're using Swashbuckle's Shouldn't Kiota just treat a single-element |
I believe, you are correct. It probably should. To resolve this, I suspect need to check what happens around here when the model declarations are being created. kiota/src/Kiota.Builder/KiotaBuilder.cs Line 1824 in 8c4e39f
@bkoelman Would by any chance be willing to submit a PR for a failing test in this scenario to help out. I think the test would look very similar to this one.
|
I wish there were more hours in a day. It's taken me weeks before finding time to create the minimal repro, which was needed to know if we were doing something wrong. I'd like to contribute, but don't expect to be able to anytime soon, unfortunately. |
I just tested this with the latest preview from yesterday. This is fixed by #4381 |
And why generate type names with an underscore and lowercase, which goes against .NET naming conventions? I've seen this happen in other places too, pretty ugly. |
Re-opening this one for now to investigate |
Thanks for trying to fix this. Unfortunately, it's still broken. I've tested with the binary downloaded from the Duplicate types are not being generated anymore, but now the declared type of the The declared type of "todoItemPrimaryResponseDocument": {
"required": [
"data"
],
"type": "object",
"properties": {
"data": {
"allOf": [
{
"$ref": "#/components/schemas/todoItemDataInResponse"
}
]
},
"included": {
"type": "array",
"items": {
"$ref": "#/components/schemas/dataInResponse"
}
}
},
"additionalProperties": false
} Edit: Corrected the wrong OAS snippet. |
@andrueastman Can you please revert the changes from the last PR, #4694? Our code doesn't compile anymore with it, whereas before it was just annoying that we had to duplicate logic. And can you reopen this issue until a fix is available? |
Re-opening this one to investigate |
This should also be resolved with changes in #4723 |
Confirming this works properly now. Thanks! |
Thanks for confirming @bkoelman |
When using inheritance using
allOf
, Kiota generates multiple identical classes for the same component schema. As a result, the types are incompatible when trying to consume the C# code generated by Kiota.I've tried to create a minimal repro, but the OAS is still quite large. The full file is provided below. At a high level, the structure contains the following base component schema:
with derived schemas
tagDataInResponse
andtodoItemDataInResponse
, ie:These schemas are used from two GET endpoints, one returning a collection and the other a singular item. The response schema in both cases contains a
data
property (derived schema reference, or an array of that) and anincluded
property (array of base schema reference).The first endpoint (
paths./api/todoItems.get
) uses the following response schema:And the second endpoint (
paths./api/todoItems/{id}.get
) uses the following schema:I would have expected Kiota to generate the base class
DataInResponse
, with the two derived classesTodoItemDataInResponse
andTagDataInResponse
. What happens is that Kiota also generates the derived classTodoItems
, whose content is identical toTodoItemDataInResponse
. The unexpectedTodoItems
class is only used by the singular endpoint.As a result, it's not possible to define a method that takes a parameter of type
TodoItemDataInResponse
and is called with the response from both endpoints. I would have expected to be able to write:Instead, the code for method
PrintTodoItem
needs to be duplicated, because the types are incompatible:Additionally, because there are duplicate types, it's unclear for consumers of the API what to upcast/type-check for when looping over the entries in
included
.When using NSwag to generate the client, types appear as expected, which makes me believe the OAS is correct.
Expand to view the full OAS file
I'm using the next command to generate the client code:
Used versions:
The text was updated successfully, but these errors were encountered: