-
Notifications
You must be signed in to change notification settings - Fork 75
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
Fix non-azure openai generation issues - part 1 #2041
Conversation
import { assert } from "chai"; | ||
import { customBearerTokenAuthenticationPolicy } from "../util/customBearerTokenTestingPolicy.js"; | ||
|
||
describe("OAuth2Context in API Layer", () => { |
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.
We can only change underlying policy in API layer and can't do this in classical layer. This is a breaking for mgmt SDK, I was wondering if we need to re-visit this design.
@qiaozha How do you think?
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.
Based on our past experience when handling the customer issues for mgmt plane, we do recommend our customers to use customized policy for serveral times. Personally, I don't think it worth a breaking here to recommend them to custom it in the api layer.
If we want to have an exact same user experience like mgmt plane to use client.pipeline.addPolicy()
and client.pipeline.removePolicy()
, we have to add a new property in the classical client layer.
public pipeline: Pipeline;
and change the constructor like
export class ApiKeyClient {
private _client: ApiKeyContext;
public pipeline: Pipeline;
/** Illustrates clients generated with ApiKey authentication. */
constructor(credential: KeyCredential, options: ApiKeyClientOptions = {}) {
this._client = createApiKey(credential, options);
this.pipeline = this._client.pipeline;
}
...
}
Not sure if others have different opinions or have other options about it. @joheredi thoughts ?
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.
I prefer to have a pipeline
in classical client first and we could refactor these logic to core whenever necessary in future. @joheredi Not sure you have any concern?
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.
updated in commit ab2632b
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.
why not change the test into using the classical client layer pipeline ?
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.
autorest.typescript/packages/typespec-ts/test/modularIntegration/authUnion.spec.ts
Line 77 in 6378211
describe("UnionClient in classical client", () => { |
@joheredi I merged this pr but feel free to add any comment if you have! |
this is part of the issue #2042 and fixes #2046.