error generating the client: The path '...' is too long, or a component of the specified path is too long.

[galvesribeiro]

Hello folks!

While trying to use Kiota to genera a client for this OpenAPI schema, it is generating classes with strange big names like this:

I've noticed in other schemas it concatenating pieces of the schema with _ on the class names but it was always two or three pieces. Now, for whatever reason, it is getting massive and eventually the generation fail with this:

crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: The path '/Users/guto/dev/repos/OTA/TravelPlatform/src/TP.GDS.Sabre/CreatePassengerNameRecord/Models/CreatePassengerNameRecordResponse_CreatePassengerNameRecordRS_TravelItineraryRead_TravelItinerary_ItineraryInfo_ReservationItems_Item_Product_ProductDetails_Lodging_Rooms_Room_RatePlan_RateInfo_Guarantee_GuaranteesAccepted_GuaranteeAccepted_PaymentCards_PaymentCard.cs' is too long, or a component of the specified path is too long.

Is there something we can do to avoid this behavior even if we have to hack the OpenAPI spec?

To give you an idea, other schemas from the same company/service properly generate the subdirectories to hold the models:

Thanks!

[baywet]

Hi @galvesribeiro,
Thanks for using kiota and for reaching out.

This behaviour happens when property schemas are defined inline.
For example with CreatePassengerNameRecordRequest_CreatePassengerNameRecordRQ:

1. there is a component schema named CreatePassengerNameRecordRequest
2. this schema has a CreatePassengerNameRecordRQ property
3. the schema for this property is defined inline (where the property is defined)

To clean this up and achieve better reusability:

1. move the schema of the property to its own reusable component schema.
2. use a $ref in the property instead.

Let us know if you have further questions.

[galvesribeiro]

Thanks for getting back @baywet. I'll try hack around the schema to have dedicated components.

I think those inline schemas are legit and supported by the openAPI spec. Wouldn't be better if the generator understood them and generate the classes properly?

Will report back the outcome.

[baywet]

Sure, what we've introduced after the first iteration of the dotnet generation is the notion of "CodeFile", they are effectively logical groupings of code elements (classes, interfaces,...) that are not namespaces.

We could tweak the generation to group all inline types with their main types (i.e. everything under the request body in that source file, everything under the response body with that file, same for query parameters....). This way kiota clients would be less likely to hit file length limitations, wouldn't have to change the description and would still get the same experience.

If this is something you're interested in working on, let me know, I'll give you pointers.

[galvesribeiro]

Yeah sure, I can help with a PR if you show me the directions, never had dive on Kiota code before, good opportunity.

I was thinking that when the schema is loaded, somehow a model is built from it. So, if the schema property is defined inline, and the property itself is a complex type (i.e. have other properties) then it should be extracted as its own class, otherwise, if it is a simple type, then just add a property on the current type (loop). The same would go from the top-level schema all the way down to the bottom and inner-most property declaration.

[baywet]

Great!

Here are a couple of pointers:

• this is a good example on how to group elements into a code file
• then you'll need to introduce a writer for the code file start as well as one for its end (for the content, it's going to be a mix between those examples and the code class declaration/end writers in C#)
• the unit tests for the refiner should go here
• the unit tests for the new writers should be added in the same folder as this one

Let me know if you have further questions!

[galvesribeiro]

Chill bot, it is holiday :) Will get to this early 2024.

[galvesribeiro]

Calm down bot. I'll be back.

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[sebastienlevert]

Hello @galvesribeiro! Let us know if you are still interested into this topic! For now, we'll close it as it's really a usability issue rather than an actual bug, but if you want to help with this issue, let us know and we will re-open the issue! Thanks!

[galvesribeiro]

Sure. I'm out on vacation returning next month. Will update here and make PR when I get back.

Thanks!