Fix non-idempotent model class descriptions for shared component schemas (#7927) - #7954
Merged
Vincent Biret (baywet) merged 2 commits intoJul 20, 2026
Conversation
…mas (#7927) The class-level description was sourced from the schema reference's own (sibling) description, which describes the property/usage site rather than the model. When a component is referenced from multiple properties with different descriptions (built by parallel tasks), the winning description was non-deterministic, breaking idempotency (e.g. notion.com). Derive the class description from the schema definition/target instead, so it is identical regardless of which reference triggers creation. The reference-level description remains used for the property description. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ffeb05ef-e52d-4702-be93-efebb0d15dbc
Contributor
Code Coverage OverviewLanguages: C# C# / code-coverage/dotnetThe overall coverage in commit 1de07a8 in the Show a code coverage summary of the most covered files.
Updated |
Vincent Biret (baywet)
approved these changes
Jul 20, 2026
Vincent Biret (baywet)
left a comment
Member
There was a problem hiding this comment.
Thanks for the contribution!
Vincent Biret (baywet)
enabled auto-merge (squash)
July 20, 2026 16:14
Vincent Biret (baywet)
deleted the
gavinbarron/fix-7927-model-description-idempotency
branch
July 20, 2026 16:18
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7927
Problem
When an OpenAPI component schema is referenced directly as the type of multiple properties, and those
$refsites carry different siblingdescriptions, Kiota could emit a different class-level description on each run (idempotency failure). Reproduced withnotion.com, where the componentinternalFileResponseis$ref'd from several properties, each$refadding its own description (e.g. "The file URL for the cover.", "The file URL for the icon.").Root cause
KiotaBuilder.AddModelClasssourced the classDescriptionTemplatefromschema.Description. For anOpenApiSchemaReference,.Descriptionreturns the reference object's own (sibling) description first, falling back to the target only when absent. Since models are built by parallel tasks and the same class can be reached from several$refsites, which sibling description "wins" was non-deterministic.Fix
Derive the class description from the schema definition/target (via a new
GetModelClassDescriptionhelper): useschemaRef.Targetfor references, otherwise the schema itself, then apply the existing own-description → non-referencedallOffallback. This makes the class description identical regardless of which reference triggers creation. The reference-level (property) description path inCreatePropertyis unchanged and still describes the property.This matches the behavior defined by Vincent Biret (@baywet) in the issue:
allOfcrawl retained as a fallback.Tests
Added two regression tests in
KiotaBuilderTests.cscovering the shared-component scenario with differing$refdescriptions, with and without a target description. Verified they fail against the pre-fix code and pass after. FullKiotaBuilderTests(336) and the description/inheritance/allOf suites (164) pass with no new warnings.