-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Client SDK renaming and also fix incorrect TypeSpec for SupportedModels #39021
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
… analyzer warning
…and embedding fields
Next Steps to MergeNext steps that must be taken to merge this PR:
Comment generated by summarize-checks workflow run. |
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.
Pull request overview
This PR makes two focused improvements to the ContentUnderstanding TypeSpec specification: correcting the data structure for supported models and standardizing client-side naming.
Key Changes:
- Fixed
SupportedModelsto usestring[]instead ofRecord<string>for completion and embedding models, correctly representing an array of model names rather than a dictionary - Added client-side renaming of
ContentCategoryDefinitiontoContentCategoryto resolve .NET analyzer warnings (AZC0031) and maintain consistency across all SDK languages
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| specification/ai/ContentUnderstanding/models.tsp | Corrects the type definition of SupportedModels.completion and SupportedModels.embedding from dictionaries to string arrays |
| specification/ai/ContentUnderstanding/client.tsp | Adds @@clientName decorator to rename ContentCategoryDefinition to ContentCategory in generated SDKs for all languages |
API Change CheckAPIView identified API level changes in this PR and created the following API reviews
|
Data Plane API Specification Update Pull Request
Tip
Overwhelmed by all this guidance? See the
Getting helpsection at the bottom of this PR description.PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.
API Info: The Basics
Most of the information about your service should be captured in the issue that serves as your API Spec engagement record.
Is this review for (select one):
Change Scope
This section will help us focus on the specific parts of your API that are new or have been modified.
Please share a link to the design document for the new APIs, a link to the previous API Spec document (if applicable), and the root paths that have been updated.
Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the
Generated ApiViewcomment added to this PR. You can use ApiView to show API versions diff.Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
Release planner
A release plan should have been created. If not, please create one as it will help guide you through the REST API and SDK creation process.
❔Got questions? Need additional info?? We are here to help!
Contact us!
The Azure API Review Board is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our wiki.
Click here for links to tools, specs, guidelines & other good stuff
Tooling
Guidelines & Specifications
Helpful Links
Getting help
write accessper aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositoriesNext Steps to Mergecomment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.and https://aka.ms/ci-fix.
queuedstate, please add a comment with contents/azp run.This should result in a new comment denoting a
PR validation pipelinehas started and the checks should be updated after few minutes.