-
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 some issues with API version handling in new getClient #2738
Conversation
...st/test/NetworkAnalytics.Management/generated/typespec-ts/src/api/networkAnalyticsContext.ts
Show resolved
Hide resolved
...s/typespec-test/test/anomalyDetector/generated/typespec-ts/src/api/anomalyDetectorContext.ts
Show resolved
Hide resolved
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.
If the purpose of the following change
- const updatedOptions = {
+ const { apiVersion: _, ...updatedOptions } = {
is just remove apiVersion from the option, we should always do that, otherwise, for cases like this one apiVersion is required parameter
const updatedOptions = { |
If |
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 think the changes look good. I don't think there are problems when apiVersion is required. If user ends up passing it also in the options, it is good they get the warning from core.
We will only get warning from core after Azure/azure-sdk-for-js#29904 is merged and we bump the core version, otherwise the current logic will just append a api-version query parameter as the ApiVersionPolicy is in core no matter if the client side has an api version or not. But, in order to get Azure/azure-sdk-for-js#29904 merged, we need codegen to be correctly and explicitly not pass the api version to core if it's not supported and refresh all the existing RLCs as suggested by Azure/azure-sdk-for-js#29883 (comment) step 3, the order is tricky, but I feel like we have to remove it until @xirzec 's PR get merged 😞 |
ff6b4b8
to
d9a97e8
Compare
Updated to always destructure the API version, regardless of whether the apiVersion parameter is required, optional, or present at all |
5bc89ee
to
451a9cc
Compare
A couple of bug fixes as a follow up to #2728:
@server
decorator, like we do for other params. This fixes the "parametrizedHost" smoke test's apiVersion param not having a default value set.apiVersion
optionwhen it is presentbefore passing the options togetClient
. This prevents the Core policy from picking it up.