Kiota should resolve polymorphic references (oneOf, allOf, anyOf) for request bodies when generating sliced OpenAPI for plugin

[maisarissi]

Today, Copilot plugins don't support polymorphic references (oneOf, allOf, anyOf) and circular references in OpenAPI descriptions.

For circular references, we shouldn't do anything and just throw an error as we can't know for sure how many degrees of separation should be considered, or how the user would like to resolve it, and giving control to the users to influence the behavior would be even more complex.
Note: Circular references moved to a separate issue, #5381

For polymorphic references in request bodies, rather than failing on plugin generation, Kiota should:

• inline allOfs
• pick the first entry for anyOfs and oneOfs

For allOfs, anyOfs and oneOfs in responses, we shouldn't do anything and just keep as it is. We shouldn't throw an errors as well.

[baywet]

This is really ambiguous. What do you expect to happen when a circular pattern is detected? drop the property causing it?
What about multiple degrees of separation? (group, members, user, memberof) how many degrees of separation should be considered here?
Should we give any control to the user to influence the behaviour here? (e.g. what if I really care about group members, but not user member of, but for some reason kiota is trimming properties the other way around from what I want?)

[petrhollayms]

@darrelmiller How do you see it for GA?

[maisarissi]

I've updated the description based on internal discussion with @baywet and @darrelmiller
@petrhollayms we should be good to go.

[calebkiage]

Question, shouldn't we fail for anyOf and oneOf? Otherwise, we'll get a bunch of bug reports because picking the first entry will change the meaning of the schema.

[petrhollayms]

@maisarissi I am also asking myself this question on your initial description:

For allOfs, anyOfs and oneOfs in responses, we shouldn't do anything and just keep as it is. We shouldn't throw an errors as well.

Are we assuming there won't be multiple entries or why would the first item work otherwise?
@darrelmiller Any thoughts here?

[maisarissi]

After some discussion with @baywet and @darrelmiller, we realized that yes, picking the first one is not the best solution, however, seems to be the least worst option.
Otherwise, the other option would validate whether the OpenAPI has oneOf/anyOf for the selected paths, and throw an error. This would eliminate several (if not almost all) uses cases for the users.

[calebkiage]

I have another question about the expectation for allOf. In case I have a schema with allOf defined like:

schema:
  allOf:
  - type: string
  - type: number

should the slicing fail?

[baywet]

@calebkiage this specific example is impossible to resolve at runtime RFC
So yes, I believe that constraints which are impossible to resolve should result in a failure. Alternative being to select one of the entries, which could have undesired side effects.