Skip to content
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

support modular models in multiclient #2556

Closed

Conversation

kazrael2119
Copy link
Contributor

@kazrael2119 kazrael2119 commented Jun 4, 2024

fixes #2554
fixes #2611

see design doc.

Discussion Conclusion:

Model Generation:

  • Decision: All models will be generated under the models/ directory.
  • Rationale: This standardizes the location for model files, making it easier to manage and locate them.

Name Collision Detection:

  • Decision: Implement a mechanism to detect name collisions among the models.
  • Suffix Strategy: In cases of name collisions, suffix the model names with _N where N is a unique number.
  • Rationale: This approach ensures unique model names, preventing conflicts during generation.

Handling Name Collisions (Process):

  • Action Required: Library authors should resolve name conflicts identified by the _N suffix during code review or API review.
  • Resolution Methods:
    • Use the @clientName attribute to specify unique names.
    • Update the specification to avoid name collisions.

Warning and Reporting:

  • Emitter Output: The emitter should generate a warning listing the models with name collisions.
  • Actionable Steps: Provide actionable steps for resolving these collisions, such as reviewing and updating model names or specifications.

Action Items

  • implement single model subpath export.
  • detect name collision
  • handle name collision
  • report diagnostic warning
  • add document on how to resolve the warning

@qiaozha qiaozha marked this pull request as ready for review June 5, 2024 06:50
Copy link
Member

@qiaozha qiaozha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good candidate for smoke test as it has serialize utils for multi sub client clients in Modular. @joheredi Let me know if you have any concerns.

}

/** serialize function for ChatRequestMessageUnion */
export function serializeChatRequestMessageUnion(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joheredi, Currently getAllModels are not bounded by the client decorators, so even if we have generate the models/models.ts in several different subclient's folder, they are actually redundant, and serializeUtils are bound with the models, in this fix, they are also redundant https://github.com/Azure/autorest.typescript/pull/2556/files#diff-182a11512248c84c2b807878be3b3743021b2565342194c7b77d269fefdcba59

I vaguely remember we have some discussion about this, when we support multiclient in modular, the conclusion is that we should make sure to have subpath export for both api and models for each subclient.

@qiaozha qiaozha self-assigned this Jul 3, 2024
@qiaozha qiaozha changed the title add ai modelClient smoke test support modular models in multiclient Jul 4, 2024
@qiaozha qiaozha marked this pull request as draft July 16, 2024 02:58
@qiaozha
Copy link
Member

qiaozha commented Jul 16, 2024

Summary of changes in this PR:

  1. move models.ts and pagingTypes.ts from subpath export ./subClient/models to the top level ./models
  2. move ./subClient/models/options.ts and ./models/options.ts to api layer as operation option is closely tied to operations.
  3. re-export all models in the subclient classical layer.
  4. remove the export of XXXClientOptions in classical client. instead of export it from the api layer because we would need to re-export all the operation options to the top level anyway.
  5. add diagnostic of "duplicate-model-name" and report it during model name conflict detection.
  6. rename rlc option enableModelNamespace into autoResolveModelConflict and changing the rename strategy from add namespace prefix into add number N suffix. And because we have normalize name logic for model name _N suffix will be normalized into N suffix, it would be risky to just remove normalization in order to keep _N suffix, as we discussed before.

@qiaozha qiaozha marked this pull request as ready for review July 16, 2024 07:07
],
"exclude": [],
"compilerOptions": {
"outDir": "../.tshy-build/browser"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should remove files under .tshy?

@@ -2,7 +2,7 @@
// Licensed under the MIT license.

/** The response of entire anomaly detection. */
export interface UnivariateUnivariateEntireDetectionResultOutput {
export interface UnivariateEntireDetectionResultOutput {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems we have name collisions here(that's why we have prefix with namespace before), but i didn't notice any name suffix with _N, could you share the link with me?

@@ -9,31 +9,31 @@ import { OperationOptions } from '@azure-rest/core-client';
import { Pipeline } from '@azure/core-rest-pipeline';

// @public (undocumented)
export interface A {
export interface A0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haha, we start with _0? i was wondering if we just keep A as A for the first one?

@@ -465,6 +459,7 @@ export interface ChatRequestUserMessage extends ChatRequestMessage {
// @public
export interface ChatResponseMessage {
content: string | null;
// Warning: (ae-forgotten-export) The symbol "AzureChatExtensionsMessageContext" needs to be exported by the entry point index.d.ts
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could fix this warning?

@@ -129,12 +129,6 @@ export interface AzureChatExtensionDataSourceResponseCitation {
url?: string;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this expected? it seems relevant to this change: #2556 (comment).

nameSet.set(model.name, [
...nameSet.get(model.name)!,
model.__raw! as Model
]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: could we directly add items into original array? so that we don't need to build a new array every time.

@@ -19,6 +19,7 @@ import {
serializeRequestValue
} from "./helpers/operationHelpers.js";
import { ModularCodeModel, Type } from "./modularCodeModel.js";
import path from "path/posix";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why path/posix not path directly? it seems posix would stick to posix style, not sure if we have issue in non-unix environement https://nodejs.org/api/path.html#windows-vs-posix?

import { KnownMediaType } from "./mediaTypes.js";

export interface SdkContext extends TCGCSdkContext {
rlcOptions?: RLCOptions;
generationPathDetail?: GenerationDirDetail;
hasApiVersionInClient?: boolean;
nameModelMap?: Map<string, Model[]>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you know we have a ContextManager, i was wondering if saving this information into there would be more proper?

@@ -61,7 +61,7 @@ function extractRLCOptions(
dpgContext,
emitterOptions
);
const enableModelNamespace = getEnableModelNamespace(
const autoResolveModelConflict = getEnableModelNamespace(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we change the getter function name here also?

@@ -64,15 +67,37 @@ export function getOperationNamespaceInterfaceName(

export function detectModelConflicts(dpgContext: SdkContext) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we leverage this in RLC also? Is it problematic when we plan to get rid of tcgc dependency in RLC?

@qiaozha qiaozha mentioned this pull request Aug 20, 2024
@qiaozha
Copy link
Member

qiaozha commented Oct 9, 2024

close it as most of the change has been taken by binder pr.

@qiaozha qiaozha closed this Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

revisit modular models generation in multi clients Multiclient definitions causing crash for TS DPG
3 participants