text:
Updated to version 4.17.3

Running the hotfix for 4.17.3.
PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which has an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] If applicable, the PR references the bug/issue that it fixes in the description.
[ ] New Unit tests were added for the changes made and CI is passing.

Can you cherry-pick these commits in as well?

source: gharchive/pull-request

authors: VpOfEngineering v-smanchem

repo: Azure/azure-functions-docker

license: MIT

license_type: permissive

license_source: github-api


text:
Explain the basis for last sync version selection in comment

This issue tracks the fix to address the code review comment in #226.
Please add info about why this is done to the comment - we want to be able to know why unintuitive stuff like this was done without having to dig up the design doc for everything.
Originally posted by @Charles-Gagnon in https://github.com/Azure/azure-functions-sql-extension/pull/226#discussion_r931507585

Read up on this in the design doc and this is what I understand for the decision of new last sync version.

Since the batch of changes are acquired in ascending order. With multiple version numbers in the batch, the other changes with version numbers that are below the highest version number should either be already processed or being leased by other workers, which is why last sync version is updated to second highest version number.
In the query where the last sync version is actually updated in the GlobalState Table it checks if there are any unprocessed changes with version numbers lower than new last sync version. If there are none, every change with version number <= new last sync version is cleared from the Leases Table.
It is ensured that a worker lagging behind won't update the last sync version to a lower version due to condition of updating only when @current_last_sync_version < {newLastSyncVersion}.

Was trying to think of scenarios where this might fail, but seems good enough to me.
Will create a PR adding comments for it.

source: gharchive/issue

authors: AmeyaRele JatinSanghvi

repo: Azure/azure-functions-sql-extension


text:
IncludeTotalCount with Node.JS Server SDK not working

Hi,
I trying use Android SDK with azure mobile apps nodejs server sdk, but when I use includeTotalCount don't return results.
Thanks

@educosta We haven't heard back from you. I'm closing the issue for now but please feel free to reach out to us if you have any questions. Thanks!

authors: educosta elamalani

repo: Azure/azure-mobile-apps-android-client

license_source: bigquery


text:
SignalR support

It would be nice to have SignalR support embedded in the library. WebAPI 2 already generates a JavaScript file for the proxy, so it should be relatively easy to just point to that endpoint, fetch the proxy and make sure the SignalR authentication is already dealt with using the bits and pieces available within the mobile apps client.

Hi @jsiegmund - can you please post this feature request in our UserVoice at http://feedback.azure.com - this would be long-range and would actually have impact across all the client platforms, so I want to get it stored in the right place.

Sure, done! https://feedback.azure.com/forums/34192--general-feedback/suggestions/13123275-provide-signalr-support-for-azure-apps-cordova-cli

authors: adrianhall jsiegmund

repo: Azure/azure-mobile-apps-cordova-client


text:
Validating items property must exist for an array type

Addresses https://github.com/Azure/autorest/issues/1962

@dsgouda,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

authors: dsgouda msftclas

repo: Azure/azure-open-api-validator


text:
Linux Env Setup and steps

There are steps added if the users want to deploy from a linux VM

Created an MD file to show the linux setup steps

Moved the Linux setup steps to and MD file.

repo: Azure/azure-openai-landing-zone


text:
Compute 2021 03 API release

Update: moved to this PR for the required commit history format: https://github.com/Azure/azure-rest-api-specs/pull/14223
This PR is to release the new version of Compute, 2021-03-01.
This release consists of these PR, all of which have been reviewed before:

Deep Deletion: https://github.com/Azure/azure-rest-api-specs/pull/13657
Scheduled Events: https://github.com/Azure/azure-rest-api-specs/pull/13351
PatchSetting Assessment mode: https://github.com/Azure/azure-rest-api-specs/pull/13468
Network Interface Config :https://github.com/Azure/azure-rest-api-specs/pull/13449  (Required and received ARM signoff)
Patchsetting Description : https://github.com/Azure/azure-rest-api-specs/pull/13509
RestorePoint: https://github.com/Azure/azure-rest-api-specs/pull/13219 (Required and received ARM signoff)
UserData: https://github.com/Azure/azure-rest-api-specs/pull/13220
https://github.com/Azure/azure-rest-api-specs/pull/14191
https://github.com/Azure/azure-rest-api-specs/pull/14197

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[x] SDK of .NET (need service team to ensure code readiness)
[x] SDK of Python
[x] SDK of Java
[x] SDK of Js
[x] SDK of Go
[x] PowerShell
[x] CLI
[ ] Terraform
[ ] No, no need to refresh for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
[ ] Ensure to copy the existing version into new directory structure for first commit (including refactoring) and then push new changes including version updates in separate commits. This is required to review the changes efficiently.
Adding a new service

[x] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

The .Net SDK PR check error was introduced by this PR: https://github.com/Azure/azure-rest-api-specs/pull/14095/files
It is not related to my changes in this PR.

The breaking change compared to the 2016 version is not a valid failure.
The breaking change compared to the 2012 version (the enum constraint weakening) was approved in this PR: #13220

The APIDocPreview error is expected.
The error can be resolved after this swagger version releases and I update https://github.com/Azure/azure-docs-rest-apis/blob/a3471166348cdcb19ecff2bba982523939796784/mapping.json#L1156
This also occurred in the 2012-12-01 release and the Doc team advised this post-release fix.

The ARM team also reviewed the 2 PRs in this release that need ARM signoff.

Ensure to copy the existing version into new directory structure for first commit (including refactoring) and then push new changes including version updates in separate commits. This is required to review the changes efficiently.

@chiragg4u , apologies for not having that setup.
The Commits that were used to setup the branch for the new version are:
https://github.com/Azure/azure-rest-api-specs/pull/14121/commits/d5b214613e6e983c750234c1291acf385d2f0363
https://github.com/Azure/azure-rest-api-specs/pull/14121/commits/e45d32a312256daa40281f16c2a460f99b3f7073
https://github.com/Azure/azure-rest-api-specs/pull/14121/commits/840f44ef1014b803627ebf644c819dfd1144939a
https://github.com/Azure/azure-rest-api-specs/pull/14121/commits/134aa5823a723c8add0a973b7740a943ef61ef91
https://github.com/Azure/azure-rest-api-specs/pull/14121/commits/29a5ff6e6b017c80430e568099ebf9cd90b8df98
The changes merged with new features for this release are listed in the initial PR comment as separate PRs.

If you want to get faster review please follow the recommended pattern. I won't be able to review this PR in current form, sorry!

In reply to: 829242309

Hi, @Sandido. The PR has be closed for a long time and it's related branch still exist. Please tell me if you still need this branch or i will delete it in 14 days.

Hi, @Sandido. The PR has be closed for a long time and it's related branch still exist. Please tell me if you still need this branch or i will delete it in 14 days.

Hi, @Sandido. The PR has be closed for a long time and it's related branch still exist. Please tell me if you still need this branch or i will delete it in 14 days.

authors: JackTn Sandido chiragg4u

repo: Azure/azure-rest-api-specs


text:
[SQL] Add EndpointCertificates API to V5 SDK tag

Adding EndpointCertificates API to V5 SDK tag, and bumping version to 2021-11-01 for ServerTrustCertificates and DistributedAvailabilityGroups
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[x] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[x] SDK of .NET (need service team to ensure code readiness)
[x] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@raych1 is there anything I can do regarding CI errors, or we can merge this?


text:
Append with Flush

Continues from https://github.com/Azure/azure-rest-api-specs/pull/18546

@seanmcc-msft yes but I'm not sure why the CI won't finish. Until is passes I can't click the button :(

/azp run public.rest-api-specs

/azp run openapi-pipeline-app

@seanmcc-msft is this an incremental change to a yet-unreleased service version? See the breaking change failure.

This change was introduced several years ago, but was not enabled in production until now.

Then that sounds like this is a breaking change if the production service has changed to add this new optional property...?

This change was introduced several years ago, but was not enabled in production until now.

Then that sounds like this is a breaking change if the production service has changed to add this new optional property...?

The feature may have been active in production for a while already, but not documented.  In some cases, our swagger files represent a subset of the functionality of the service.

@tjprescott can we merge this?

Adding the Approved-BreakingChange label.

It looks like there's a linter rule that might need to be addressed still around an extra x-ms-client-name that's the same as the parameter name?

It looks like there's a linter rule that might need to be addressed still around an extra x-ms-client-name that's the same as the parameter name?

I have removed the x-ms-client-name for the flush parameter.

authors: seanmcc-msft tg-msft tjprescott


text:
[Workloads - Sap Virtual Instance]

ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

The model validation error is not related to this change.

@tadelesh, could you help to check the SDK breaking change in GO?

Approve for Go breakings as all come from lack of -alwaysSetBodyParamRequired flag. cc @Alancere

authors: dmadiraju1 lirenhe tadelesh


text:
Release api management 2022 08 01

ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[x] Other, please clarify - Added new things to a new API version.

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

@mcallisterjp Please help to resolve the ci issues.

authors: malincrist tadelesh


text:
Adding changes for Distributed Node info list along with new API version 2023 04 01 for RecoveryServicesBackup

ARM API Information (Control Plane)
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki. Note that this doesn't apply if you are trying to merge a PR that was previously in the private repository.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

    "isProtectable": {

ARM recommends string enums over booleans. Generally enums make better properties than booleans. They are more descriptive and flexible while being easier for customers to discover, understand and use. Ref: https://armwiki.azurewebsites.net/rp_onboarding/process/api_review_best_practices.html?q=boolean#common-issues-found-in-review. They allow values other than just true/false and support description strings. Even if you only ever want two values, you can have a string enum with True/False (or Enabled/Disabled, etc.).
This AzureVmWorkloadProtectableItem type highlights another reason: a vector of booleans is harder to use. This object has isAutoProtectable, isAutoProtected, and isProtectable creating 8 combinations and is confusing to use. Using an enum is easier to understand and helps eliminate invalid combinations. I'd suggest something like:
protectability: { None, Manual, Auto }
currentProtection: { None, Manual, Auto }

Refers to: specification/recoveryservicesbackup/resource-manager/Microsoft.RecoveryServices/stable/2023-04-01/bms.json:10121 in 35fde2b. [](commit_id = 35fde2bfec81598a849f6a9194dc08994c8872d4, deletion_comment = False)

    "isProtectable": {

ARM recommends string enums over booleans. Generally enums make better properties than booleans. They are more descriptive and flexible while being easier for customers to discover, understand and use. Ref: https://armwiki.azurewebsites.net/rp_onboarding/process/api_review_best_practices.html?q=boolean#common-issues-found-in-review. They allow values other than just true/false and support description strings. Even if you only ever want two values, you can have a string enum with True/False (or Enabled/Disabled, etc.).
This AzureVmWorkloadProtectableItem type highlights another reason: a vector of booleans is harder to use. This object has isAutoProtectable, isAutoProtected, and isProtectable creating 8 combinations and is confusing to use. Using an enum is easier to understand and helps eliminate invalid combinations. I'd suggest something like: protectability: { None, Manual, Auto } currentProtection: { None, Manual, Auto }
Refers to: specification/recoveryservicesbackup/resource-manager/Microsoft.RecoveryServices/stable/2023-04-01/bms.json:10121 in 35fde2b. [](commit_id = 35fde2b, deletion_comment = False)

@mentat9 This is an existing property and has been in the GAed data contract since long time. I'm fixing a Swagger compliance issue by adding this in this version.Changing the type of this property would be a much bigger change in our services and clients. Noted the comment about enum/boolean for future reference. Could you please review the other set of changes. Also the Avocado is expected to fail for RecoveryServicesBackup because we have the swagger for both active and passive stamps.

    "isProtectable": {

ARM recommends string enums over booleans. Generally enums make better properties than booleans. They are more descriptive and flexible while being easier for customers to discover, understand and use. Ref: https://armwiki.azurewebsites.net/rp_onboarding/process/api_review_best_practices.html?q=boolean#common-issues-found-in-review. They allow values other than just true/false and support description strings. Even if you only ever want two values, you can have a string enum with True/False (or Enabled/Disabled, etc.).
This AzureVmWorkloadProtectableItem type highlights another reason: a vector of booleans is harder to use. This object has isAutoProtectable, isAutoProtected, and isProtectable creating 8 combinations and is confusing to use. Using an enum is easier to understand and helps eliminate invalid combinations. I'd suggest something like: protectability: { None, Manual, Auto } currentProtection: { None, Manual, Auto }
Refers to: specification/recoveryservicesbackup/resource-manager/Microsoft.RecoveryServices/stable/2023-04-01/bms.json:10121 in 35fde2b. [](commit_id = 35fde2b, deletion_comment = False)

@mentat9 This is an existing property and has been in the GAed data contract since long time. I'm fixing a Swagger compliance issue by adding this in this version.Changing the type of this property would be a much bigger change in our services and clients. Noted the comment about enum/boolean for future reference. Could you please review the other set of changes. Also the Avocado is expected to fail for RecoveryServicesBackup because we have the swagger for both active and passive stamps.

@mentat9 could you please review this

    "isProtectable": {

ARM recommends string enums over booleans. Generally enums make better properties than booleans. They are more descriptive and flexible while being easier for customers to discover, understand and use. Ref: https://armwiki.azurewebsites.net/rp_onboarding/process/api_review_best_practices.html?q=boolean#common-issues-found-in-review. They allow values other than just true/false and support description strings. Even if you only ever want two values, you can have a string enum with True/False (or Enabled/Disabled, etc.).
This AzureVmWorkloadProtectableItem type highlights another reason: a vector of booleans is harder to use. This object has isAutoProtectable, isAutoProtected, and isProtectable creating 8 combinations and is confusing to use. Using an enum is easier to understand and helps eliminate invalid combinations. I'd suggest something like: protectability: { None, Manual, Auto } currentProtection: { None, Manual, Auto }
Refers to: specification/recoveryservicesbackup/resource-manager/Microsoft.RecoveryServices/stable/2023-04-01/bms.json:10121 in 35fde2b. [](commit_id = 35fde2b, deletion_comment = False)

@mentat9 This is an existing property and has been in the GAed data contract since long time. I'm fixing a Swagger compliance issue by adding this in this version.Changing the type of this property would be a much bigger change in our services and clients. Noted the comment about enum/boolean for future reference. Could you please review the other set of changes. Also the Avocado is expected to fail for RecoveryServicesBackup because we have the swagger for both active and passive stamps.

@mentat9 could you please review this

Please follow the instructions in this comment to hand your PR back to ARM review: https://github.com/Azure/azure-rest-api-specs/pull/24210#issuecomment-1571220480. Current ARM review on-call will revisit.

@chandrikagonuguntla  check the avocado validation error [MULTIPLE_DEFAULT_TAGS] https://github.com/Azure/azure-rest-api-specs/pull/24210#issuecomment-1567088021 and try to fix it refer to https://github.com/Azure/azure-rest-api-specs/pull/24210#issuecomment-1569926384

@tadelesh  @qiaozha  help to check sdk breaking change. Approved if it's OK.

Go breaking changes are introduced in: https://github.com/Azure/azure-rest-api-specs/pull/23600, not related with this PR.

@chandrikagonuguntla check the avocado validation error [MULTIPLE_DEFAULT_TAGS] #24210 (comment) and try to fix it refer to #24210 (comment)

@jacktn Avocado is expected to fail for recoveryservicesbackup because we have swagger for both passive and active stamps hence 2 defaults.

@JackTn Could you please check comment https://github.com/Azure/azure-rest-api-specs/pull/24210#issuecomment-1588638862 and sign off on the PR

@chandrikagonuguntla check the avocado validation error [MULTIPLE_DEFAULT_TAGS] #24210 (comment) and try to fix it refer to #24210 (comment)

@JackTn Avocado is expected to fail for recoveryservicesbackup because we have swagger for both passive and active stamps hence 2 defaults.

approve avocado

@JackTn Could you please check comment #24210 (comment) and sign off on the PR

@msyyc  take a look on this pr and help merge it, Thanks

@msyyc please check comment https://github.com/Azure/azure-rest-api-specs/pull/24210#issuecomment-1590595838 and help with the merge

authors: JackTn chandrikagonuguntla mentat9 tadelesh


text:
[Hub Generated] Review request for Microsoft.DataReplication to add version preview/2021-02-16-preview

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM (Control Plane) API Specification Update Pull Request
PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

[x] New API version. (Such PR should have been generated with OpenAPI Hub, per this wiki doc.)
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix swagger quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[x] I have reviewed the general guidance on the spec PR review process: https://aka.ms/specprreview.
[x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data-plane related specifications.
[x] I commit to follow the Breaking Change Policy.
[x] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can request review from an ARM API Review board.

ARM API changes review

If you want for the ARM team to review this PR, you must add the ARMReview label.
The automation may automatically add the ARMReview label, if appropriate.
If this happens, proceed according to guidance given in GitHub comments also added by the automation.

Breaking change review
If you have any breaking changes as defined in the Breaking Change Policy,
follow the process outlined in the High-level Breaking Change Process doc.
Getting help

For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For additional help, see https://aka.ms/azsdk/support/spectools.

he issue link that you created in step 1 in this PR

Link to New RP Namespace Issue: https://github.com/Azure/azure-sdk-pr/issues/1220

@rkmanda I assigned you as @minhsuanlee was asking me for help with LintDiff failures.

For LintDiff errors LroErrorContent and OperationsApiResponseSchema, I have taken necessary steps to locally reproduce the errors but from what I can tell, the cause of the error does not seem to be valid as our schema is already following the guidelines. I even tried copy-paste the schema from types.json to our swagger directly and re-run Lint validation, it still failed.

@mayada83 if you confirm the Swagger LintDiff failure is incorrect, please add the Approved-LintDiff label. If you approve this PR on behalf of the ARM team, please add the ARMSignedOff label. Thank you!

Moving to a new PR [Hub Generated] Review request for Microsoft.DataReplication to add version preview/2021-02-16-preview #24974 as Service Name has been updated from 'azuresiterecovery' to 'recoveryservicesdatareplication'

{

Observed that your new RP is not RPaaS based RP. Non-RPaaS RPs are not allowed, unless you have got an exception. If that's the case, please forward me the RPaaS exception email/communication for your RP.

Refers to: specification/azuresiterecovery/resource-manager/Microsoft.DataReplication/preview/2021-02-16-preview/azuresiterecovery.json:1 in 5ef4eea. [](commit_id = 5ef4eea5b09ea6eb26eb92f4f7a911e20e0e9d46, deletion_comment = False)

authors: konrad-jamrozik minhsuanlee visingla-ms


text:
Added 2023-12-01 preview API for Azure Load Testing Control Plane

ARM (Control Plane) API Specification Update Pull Request

[!TIP]
Overwhelmed by all this guidance? See the Getting help section 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.

Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!

[ ] New resource provider.
[X] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix OpenAPI spec quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[X] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[X] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information
This moves the 2023-12-01-preview API version that was added in private repo to the public repository using Typespec. The changes were already reviewed and merged in this PR.
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment 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
suppressions guide to get approval.

Getting help

First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

Please remove ARMChangesRequested tag for further review after addressing comments.

/pr RequestMerge

authors: mitsha-microsoft samsaha-ms


text:
User identities in a new dictionary property

Moving user identities API surface from the list property "identityId" to a new dictionary property named "userAssignedIdentities".
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-node

Automation for azure-libraries-for-java

Automation for azure-sdk-for-python

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-go

@ravbhatnagar, this is to support merge-patch for user assigned identities.
//cc @johanste

status [as of June/13]: this api version is not yet deployed to production.

@anuchandy This API version has now been deployed.

@nkuchta can you please sync with @dochung4 [Dongwook Chung] on this comment https://github.com/Azure/azure-rest-api-specs/pull/3302#issuecomment-401498593? I assume those changes has to be made to 2018-06-01 as well.
// cc @lmazuel

@anuchandy, this change should be independent of that effort. I've asked @dochung4 to follow up with his team to get his changes reconciled into this API version.

@nkuchta thank you!, merging this PR.

Automation for azure-sdk-for-java

authors: AutorestCI anuchandy nkuchta


text:
[Storage] Fix the UseSubDomainName

This PR is to fix the issue https://github.com/Azure/azure-sdk-for-python/issues/4013
The "useSubDomain" should be “useSubDomainName” from day one.
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[x] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[x] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Can one of the admins verify this patch?

Automation for azure-sdk-for-python

Automation for azure-sdk-for-node

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go

@lmazuel
I see the PR still in review.
Let me know if any action I need to take to make it merged.

authors: AutorestCI azuresdkci blueww


text:
Adding Private Endpoints (formerly Interface Endpoints)

Reviewers Please Note
I'm creating this PR for ARM reviewers to have extra clarity on the changes to the resources.
Please do not review this PR - it can't be checked in until the network-march-release branch is ready.
Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Can one of the admins verify this patch?

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Automation for azure-sdk-for-node

Automation for azure-sdk-for-java

closed due to milestone was missed. please retarget to newer branch when it's ready

authors: AutorestCI MikhailTryakhov azuresdkci rupalivohra


text:
[Hub Generated] Review request for Microsoft.ApiManagement to add version stable/2019-01-01

If you are a MSFT employee you can view your work branch via this link.
Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java
Nothing to generate for azure-sdk-for-java

@majastrz ping!

@sergey-shandar ping on this!

authors: AutorestCI azuresdkci solankisamir


text:
Output location updates to align with PR#5397 in azure-sdk-for-python

Origin PR for changes
This PR will update the output location for swagger to reflect the newly moved files. This is intended to be a transient change.
@lmazuel for review and approval

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-java

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

authors: AutorestCI azuresdkci scbedd


text:
Create a new version of API 2020-03-31

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

You don't have permission to trigger SDK Automation.
Please add yourself to Azure group from opensource portal if you are MSFT employee,
or please ask reviewer to add comment *** /openapibot sdkautomation ***.
Please ask tih@microsoft.com (or NullMDR in github) for additional help.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: gubalasu sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Can one of the admins verify this patch?

Hi @gubalasu can you help fix 2 validation error in the check(Avocado & Prettier check)?

Hi @gubalasu can you help fix 2 validation error in the check(Avocado & Prettier check)?

I have fixed the 2 validation erros

/azp run

/azp run

/azp run

authors: AutorestCI NullMDR akning-ms azuresdkci gubalasu msftclas


text:
ignore result of function to compile on G++ 5

fixes: https://github.com/Azure/azure-sdk-for-cpp/issues/2785

/azp run cpp - core

/azp run cpp - keyvault

/azp run cpp - storage

/azp run cpp - storage

/azp run cpp - keyvault

/azp run cpp - core

/azp run cpp - core

/azp run cpp - core

/azp run cpp - core

/azp run cpp - storage

/azp run cpp - keyvault

Public pipeline g++-5 :
https://dev.azure.com/azure-sdk/public/_build/results?buildId=1063962&view=logs&j=efb8e22a-57a5-5d01-2d97-95ae9b6a04dd&t=a090feb1-5f4d-5f84-82e3-a9887e35fb99&l=15
Internal pipelines also building with g++ with tests

repo: Azure/azure-sdk-for-cpp


text:
Update vcpkg SHA

Updates vcpkg commit SHA to the current, which includes our latest releases and port manifest fixes: https://github.com/microsoft/vcpkg/tree/8150939b69720adc475461978e07c2d2bf5fb76e
There is no urgent reason, we just should be doing it periodically.

/azp run cpp - attestation

/azp run cpp - core

/azp run cpp - eventhubs

/azp run cpp - identity

/azp run cpp - keyvault

/azp run cpp - storage

/azp run cpp - tables

All public and internal pipelines (for all 8 services) are green, except for the internal pipelines for Storage (live tests).
I checked, current main does also fail with the same errors, so this PR is not causing them.
cc @Jinming-Hu

/check-enforcer override


text:
azfile: STG 91 code generation

[x] The purpose of this PR is explained in this or a referenced issue.
[ ] The PR does not update generated files.

These files are managed by the codegen framework at Azure/autorest.go.

[x] Tests are included and/or updated for code changes.
[x] Updates to module CHANGELOG.md are included.
[x] MIT license headers are included in each file.

/azp run go - azfile

repo: Azure/azure-sdk-for-go


text:
Declared new pubic API functions are private in ClientCertificateCredentialBuilder

The pfxCertificate(InputStream certificate, String clientCertificatePassword) and pemCertificate(InputStream certificate) functions introduced and declared in 1.2.0-beta.2 are private (see https://github.com/Azure/azure-sdk-for-java/blob/0579b470d43d874b559a13fb421abda9cdb07b3b/sdk/identity/azure-identity/CHANGELOG.md#new-features-1).
It's expected that the functions will be public.

I hit this also, can these be made public?
I've had to create my own credential class by copying ClientCertificateCredential
So that I can set the InputStream

Same here. We are reading the certificate from a keystore so cannot provide a file path.

authors: alexey-kadyrov-r3 mkomko timja

repo: Azure/azure-sdk-for-java


text:
Investigate using Microsoft JDK builds in CI

Microsoft provides JDK builds for LTS versions and we should investigate using them in CI rather than the default Adoptium JDK builds provided by the hosted agent. Functionality for installing a custom JDK version has already been created to support running against the latest Java version, so that could be re-used to ensure MS build get installed and cached to reduce calls to download the build. The script will need to be updated to support different build targets.
Reference: https://github.com/Azure/azure-sdk-for-java/blob/main/eng/scripts/Install-Latest-JDK.ps1

Why do we want to do this? There should be no real difference between them from our perspective.

authors: JonathanGiles alzimmermsft


text:
Fix live test pipeline - Formrecognizer

This PR:

fixes pipeline to use record mode, fr its dependency on the recordedDatat
disables tests for service regressions

/azp run java - formrecognizer - tests


text:
[AutoPR] iotcentral/resource-manager

Created to accumulate context: iotcentral/resource-manager

@jianghaolu do I need to make any other changes here? can this get merged?

authors: AutorestCI emgarten


text:
mgmt, storage enabling blob versioning

Description
Fix https://github.com/Azure/azure-sdk-for-java/issues/29105
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-storage

authors: XiaofeiCao azure-sdk


text:
[Automation] Generate Fluent Lite from commerce#package-2015-06-preview

[Automation] Generate Fluent Lite from commerce#package-2015-06-preview

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-commerce


text:
Servicebus Java SDK March 2023 release

Description
Servicebus Java SDK March 2023 release PR
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

API change check
API changes are not detected in this pull request.


text:
mgmt, deviceupdate, add live tests

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
com.azure.resourcemanager:azure-resourcemanager-deviceupdate

/azp run prepare-pipelines

/azp run java - deviceupdate - mgmt - tests


text:
Azure AI Search 2024-07-01 GA

Description
Changes for Azure AI Search's 2024-07-01 GA feature set.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
com.azure:azure-search-documents

/azp run java - search - ci

/azp run java - search - ci

authors: alzimmermsft azure-sdk


text:
Increment versions for storagecache releases

Increment package versions for storagecache releases

API change check
API changes are not detected in this pull request.


text:
Upgrade Reactor and Reactor Netty dependencies

Description
This PR is upgrading Reactor dependencies from 3.4.41 to 3.7.1 and Reactor Netty from 1.0.48 to 1.2.1. This is being done as the previous Reactor and Reactor Netty minor versions, 3.4.x and 1.0.x respectively, are end of life and no longer receiving updates.
The Azure SDKs will continue to perform version validation tests using Reactor versions 3.4.15, 3.5.0, and 3.6.0 and Reactor Netty versions 1.0.0 and 1.1.0 to ensure a baseline compatibility with common ecosystems such as Spring which leverage Reactor as well.
Looking forward into the future, eventually validation for Reactor 3.4.15 and Reactor Netty 1.0.0 can be dropped once Spring Framework 5.3 and Spring Boot 2.7 reach end of life for commercial support.

https://endoflife.date/spring-framework
https://endoflife.date/spring-boot

And possibly other versions could be dropped as well depending on ecosystem support for them in maintained versions.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.


text:
Update Monitor Query Samples, Quickstarts, and Documentation based on Beta-2 consistency review

Tracking issue to update all Samples and related documentation based on the Beta-2 consistency review on 6/24
/cc @scottaddie

Related https://github.com/Azure/azure-sdk-for-js/issues/15984

Issue addressed in - https://github.com/Azure/azure-sdk-for-js/pull/16791

authors: KarishmaGhiya joshfree

repo: Azure/azure-sdk-for-js


text:
[Event Hubs] Ensure receiver is functional

As per the API proposal in https://github.com/Azure/azure-sdk-for-js/issues/2718#issuecomment-495389630, we will now have a createReceiver() method on the Event Hub Client that returns a receiver. A skeleton is already in place for the receiver. This issue is to ensure

receiveBatch method works as expected
getEventIterator method works as expected. (See https://github.com/ramya-rao-a/azure-sdk-for-js/blob/bd6e728d6d596022b98e5ed15d705721d13db004/sdk/eventhub/event-hubs/review/track2Sample.js#L42 for usage sample)
receive method works as expected
All tests in receiver.spec.ts are updated and pass
receiver.close() should close all the underlying AMQP links. Further operations should throw error

Please note that this issue only ensures that the receive operations on the receiver works. We need to ensure #3176 is taken care of to call this feature of "createReceiver" actually complete

Done with #3356


text:
[DocumentIntelligence] Missing changes in changelog, samples and release note for GA 1.0.0

Package Name: @azure-rest/ai-document-intelligence-rest
Package Version: 1.0.0
Operating system: Not relevant
Is the bug related to documentation in

[x] README.md
[x] source code documentation
[ ] SDK API docs on https://learn.microsoft.com
[x] Changelog
[x] Release Note

Describe the bug
In version 1.0.0, some types are renamed but not all are documented.
They are all from sdk/documentintelligence/ai-document-intelligence-rest/src/outputModels.ts

AnalyzeResultOperationOutput -> AnalyzeOperationOuput

Old references in samples and readme
Not present in changelog and release note

Minor misses:

FontWeightOutput -> DocumentFontWeightOutput

Not present in changelog and release note

FontStyleOutput -> DocumentFontStyleOutput

Not present in changelog and release note

DocumentOutput -> AnalyzedDocumentOutput

Not present in changelog and release note

CopyAuthorizationOutput -> ModelCopyAuthorizationOutput

Not present in changelog and release note

commit: https://github.com/Azure/azure-sdk-for-js/commit/764472643e74cd1771009d9d7753df0ee5842939#diff-a85ae937dbbcfc0517d2e0a121380f05cc26a22c4892a7c5954168b2f96fd948R291
Additional context
False references:

https://github.com/search?q=repo%3AAzure%2Fazure-sdk-for-js path%3Asdk%2Fdocumentintelligence%2Fai-document-intelligence-rest AnalyzeResultOperationOutput&type=code

Also, I would like to add that the code samples are not correct. For example, this particular line references AnalyzeResultOperationOutput, but more samples are still referencing this renamed type
https://github.com/Azure/azure-sdk-for-js/blob/78e29303f2b86461c87431b5c506426cbc8dc680/sdk/documentintelligence/ai-document-intelligence-rest/samples/v1/typescript/src/analyzeReceipt.ts#L16C3-L16C31

authors: totolicious vsantele


text:
[Storage][Doc] call out the links to REST API

In a UX study session, one participant clicked the link in the ref doc, thinking it will have details for the SDK api, but was confused by the REST API page that was opened.
Examples in storage code:
  /**
   * Returns all user-defined metadata, standard HTTP properties, and system properties
   * for the blob. It does not return the content of the blob.
   * @see https://docs.microsoft.com/en-us/rest/api/storageservices/get-blob-properties
   *
   * WARNING: The `metadata` object returned in the response will have its keys in lowercase, even if
   * they originally contained uppercase characters. This differs from the metadata keys returned by
   * the methods of {@link ContainerClient} that list blobs using the `includeMetadata` option, which

It might be useful to call out that it links to the REST API doc
  * For more details, please check out the REST API documentation at https://docs.microsoft.com/en-us/rest/api/storageservices/get-blob-properties

There are many places of these in storage code.

I'd like to take an approach that is standard across languages here. Do we have an idea of what is the purpose of linking to REST apis from reference docs? If its about return types, then the docs will have the return type and the user should be able to follow that right?

@XiaoningLiu for question about the purpose of linking to REST API docs.
.NET has links to REST API docs too, though with different wording
https://github.com/Azure/azure-sdk-for-net/blob/888654670f74346317655f08dc7e6dd6b4967112/sdk/storage/Azure.Storage.Blobs/src/BlobClient.cs#L212

SDK interfaces are thin wrappers for RESTful APIs, while RESTful APIs are the truth, some long complex storage concepts and backgrounds are only avaiable in RESTful API documents.

@jeremymeng Perhaps we can come to a conclusion on the format to use here after discussing with rest of the crew offline?

Closing as there are no next steps planned here.

authors: XiaoningLiu jeremymeng ramya-rao-a


text:
Add AnswerFailed and CreateCallFailed event

Packages impacted by this PR
Issues associated with this PR
Describe the problem that is addressed by this PR
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
APIView has identified API level changes in this PR and created following API reviews.
@azure/communication-call-automation

authors: azure-sdk richardcho-msft


text:
[Identity] Refactor MSAL Browser Flow

Packages impacted by this PR
Issues associated with this PR
Describe the problem that is addressed by this PR
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.

Refactoring looks good to me!

authors: KarishmaGhiya azure-sdk minhanh-phan


text:
[Service Bus] [Event Hubs] Run all the tests in the browser

Remove #RunInBrowser tags
Remove greps from karma.conf

/azp run js - servicebus - tests

/azp run js - eventhubs-client - tests

/azp run js - servicebus - tests

/azp run js - servicebus - tests

/azp run js - eventhubs-client - tests

/azp run js - servicebus - tests

/azp run js - eventhubs-client - tests

/azp run js - servicebus - tests

/azp run js - eventhubs-client - tests

/azp run js - eventhubs-client - tests


text:
[Service Bus] Update relevant Docs for the update methods and and remove internal get calls

Issue - #9379

[x] Mention the updatable fields in the docs
[x] Add docs that clearly mention that the user has to do a GET operation, tweak what needs to be updated, pass it to UPDATE
[x] Remove the get operation inside the update method
[ ] Trigger live tests and fix the test failures that were depending on the internal GET operation
[x] Changelog
[ ] Update Queue and Update Topic have the docs clearly showing the updatable fields, but not for subscriptions.
https://docs.microsoft.com/en-us/rest/api/servicebus/update-queue
https://docs.microsoft.com/en-us/rest/api/servicebus/update-topic
[ ] EnableFilteringMessagesBeforePublishing is not a property on TopicDescription
Update Topic: https://docs.microsoft.com/en-us/rest/api/servicebus/update-topic
.NET API View :
https://apiview.dev/Assemblies/Review/b5d7e3304000449c859c2016f718db52#Azure.Messaging.ServiceBus.Management.TopicDescription

/azp run js - servicebus - tests

/azp run js - servicebus - tests

/azp run js - servicebus - tests

/azp run js - servicebus - tests


text:
[BUG] setting Storage Account Network DefaultAction not working

Describe the bug
Trying to set the Storage Account Firewall

From "all networks" to "selected networks".
Equivalent az command would be
az storage account update --name <storageaccount> --resource-group <rgName> --default-action Deny

Expected behavior
should change the value
Actual behavior (include Exception or Stack Trace)
nothing happens
To Reproduce
Steps to reproduce the behavior (include a code snippet, screenshot, or any additional information that might help us reproduce the issue)
public static async Task RunAsync(IAzure azure, ILogger log)
        {
            var storageAccount = await azure.StorageAccounts.GetByIdAsync(ResourceId);
            storageAccount.Inner.NetworkRuleSet.DefaultAction = Microsoft.Azure.Management.Storage.Fluent.Models.DefaultAction.Deny;
            await storageAccount.Update().ApplyAsync();
        }

Environment:

Name and version of the Library package used:
<PackageReference Include="Microsoft.Azure.Management.Storage.Fluent" Version="1.34.0" />

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

@allenjzhang do you already have an idea what is happening here?

@jsquire @allenjzhang any update on this please?

Hi @davidobrien1985.   Unfortunately, I'm just first-line triage in this case and don't have visibility.  @m-nash or @markcowl - would you be able to assist with an update?

@m-nash @markcowl do you have an update for us?

@jsquire is there any way you can get anyone to help us here?

Hi @davidobrien1985.   I'm sorry that  this has been lagging and we haven't been able to get you assistance.
@AlexGhiondea, @lilyjma:  Can you help route and escalate?

@davidobrien1985
It seems your problem is for Microsoft.Azure.Management.Storage.Fluent.
If so, would you please raise your issue on correct project site: https://github.com/Azure/azure-libraries-for-net , then related team will come to help you.
SDK Microsoft.Azure.Management.Storage is released from this repo, and it also support networkrule defaultaction.
You can see how to update it with Microsoft.Azure.Management.Storage SDK in https://github.com/Azure/azure-sdk-for-net/blob/693071ce198861750993f30da84400b40b159447/sdk/storage/Azure.ResourceManager.Storage/tests/Tests/StorageAccountTests.cs#L1192

add @xccc-msft to help on this

add @xccc-msft to help on this

@davidobrien1985 For StorageAccount, the way you tried would not work. You need to try with below to update the property:
StorageAccountUpdateParameters updateParameters = new StorageAccountUpdateParameters();
updateParameters.NetworkRuleSet.DefaultAction = Microsoft.Azure.Management.Storage.Fluent.Models.DefaultAction.Deny;
await storageManager.Inner.StorageAccounts.UpdateAsync("rgName", "saName", updateParameters, cancellationToken);

@davidobrien1985 For StorageAccount, the way you tried would not work. You need to try with below to update the property:
StorageAccountUpdateParameters updateParameters = new StorageAccountUpdateParameters();
updateParameters.NetworkRuleSet.DefaultAction = Microsoft.Azure.Management.Storage.Fluent.Models.DefaultAction.Deny;
await storageManager.Inner.StorageAccounts.UpdateAsync("rgName", "saName", updateParameters, cancellationToken);

@ftd-xccc-mdy @blueww sorry for the super long delay. We finally managed to get back to this.
It's a bit unclear to me how to initialise the storageManager client which seems to require ServiceClientCredentials and won't take Azure.Core.TokenCredential or Microsoft.Identity.Client.
Can you elaborate on this and is this from the Microsoft.Azure.Management.Storage; package?

@davidobrien1985
For the "storageManager" you refer, is it's from code shared from @ftd-xccc-mdy , if so it's from Microsoft.Azure.Management.Storage.Fluent package and @ftd-xccc-mdy should know more about it.
BTW, for  Microsoft.Azure.Management.Storage package, you can see how to use it (include how to input credential) from https://azure.microsoft.com/da-dk/resources/samples/storage-dotnet-resource-provider-getting-started/

New SDFK at https://aka.ms/azsdk/dotnet/mgmt

authors: blueww davidobrien1985 jsquire weidongxu-microsoft xccc-msft yungezz

repo: Azure/azure-sdk-for-net


text:
[BUG] ODataQuery incorrectly adds quotes to dates when building the query from an expression

Either ODataQuery incorrectly adds quotes to dates when building the query from an expression, or API-M cannot handle quoted date-values in it's queries.
The result of ToString() for the following two values should be identical, but instead the variable queryFromExpression add quotes and encodes the values. The encoding of values isn't the problem, but the addition of quotes causing API-M to throw an exception. For context, this is when we are making Report requests from Azure API-M.
var start = (DateTime.UtcNow - TimeSpan.FromDays(1));
var end = (DateTime.UtcNow - TimeSpan.FromSeconds(1));

var queryFromExpression = new ODataQuery<RequestReportRecordContract>(i => i.Timestamp >= start && i.Timestamp <= end);
var queryFromString = new ODataQuery<RequestReportRecordContract>($"timestamp ge {start:o} and timestamp le {end:o}");

Expected behavior
new ODataQuery<RequestReportRecordContract>(i => i.Timestamp >= start && i.Timestamp <= end).ToString()

should equal
$filter=timestamp ge 2020-09-30T16:47:41.9064247Z and timestamp le 2020-10-01T16:47:40.9064355Z

This is based upon what the Azure Portal makes as a request when you use the Analytics component within Azure API-M.
Actual behavior (include Exception or Stack Trace)
Instead
new ODataQuery<RequestReportRecordContract>(i => i.Timestamp >= start && i.Timestamp <= end).ToString()

equals
$filter=timestamp ge '2020-09-30T16%3A47%3A41Z' and timestamp le '2020-10-01T16%3A47%3A40Z'

which leads to the Microsoft.Rest.Azure.CloudError exception  Invalid filter clause specified: 'timestamp ge '2020-09-30T17:01:09Z' and timestamp le '2020-10-01T17:01:08Z''. being thrown.
To Reproduce
The line new ODataQuery<RequestReportRecordContract>(i => i.Timestamp >= start && i.Timestamp <= end) shouldn't contain quoted dates, or the issue is that API-M cannot support quoted dates.
I also checked the following:
new ODataQuery<RequestReportRecordContract>($"timestamp ge 2020-09-30T16%3A35%3A52Z and timestamp le 2020-10-01T16%3A35%3A51Z") is Valid, which means that the encoding isn't the issue.
new ODataQuery<RequestReportRecordContract>($"timestamp ge '2020-09-30T16%3A35%3A52Z' and timestamp le '2020-10-01T16%3A35%3A51Z'") is Invalid, which means it's the quotes that's causing the problem.
Environment:

Microsoft.Azure.Management.ApiManagement (6.0.0-preview)
Windows 10
Microsoft.NETCore.App (2.1.0)
Visual Studio 16.7.5

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

For OData V3, datetime can be enclosed in quote. Assigning to service team.

authors: TomBonnerAtTFL allenjzhang jsquire


text:
Look into implications of service removing TaskState in Analyze response

Will be deleted for all tasks as it is already included per task. How does it affect the SDK?

Wait, I must have missed this part. Why?

The service is looking into removing properties from tasks as the information is repeated in each task. I haven't looked into what it means in the SDK but from a quick look, it seems appropiate
"TasksState": {
    "properties": {
    "tasks": {
        "completed": {
            "type": "integer"
        },
        "failed": {
            "type": "integer"
        },
        "inProgress": {
            "type": "integer"
        },
        "total": {
            "type": "integer"
        },
        "entityRecognitionTasks": {
            "type": "array",
            "items": {
            "type": "object",
            "allOf": [
                {
                "$ref": "#/definitions/TaskState" // Needed
                },
                {
                "$ref": "#/definitions/EntitiesTaskResult"
                }
            ]
            }
        },

I looked in .NET and this won't be an issue for us as we actually ignore these properties and either look at the JobState or the specific task state. i.e. https://github.com/maririos/azure-sdk-for-net/tree/notaskdetails
Once the change is done in the swagger, we can consume it.

authors: deyaaeldeen maririos


text:
Only methods returning a Task<Operation<T>> are being instrumented automatically

The InstrumentResultInterceptor is only automatically intercepting and proxying methods that return a Task<Operation<T>>. This was discovered when async tests were completing in tends of milliseconds, while sync tests were taking seconds. For the Conversations SDK, that triggered the 5s local playback error.
To work around this we can manually instrument, but it'd be nice if this was automatic so we didn't have to condition code to instrument.

This is specific to SyncOnly tests. Most tests are written as async and will have their operations instrumented here. The UseSyncMethodsInterceptor runs after this to handle running the sync variant of tests. The operation instrumentation doesn't work for SyncOnly tests because the operation method doesn't return a Task.

IIRC, you had a reason why this wouldn't work but I wanted to ask it again here for posterity, but would it not be as easy as switching the order of the interceptors for instrumenting async operations (to bifurcate sync and async) and the one to instrument operations based on method signature?

I tried it, and it's not quite so simple as reversing the order. Some changes to the flow and method name calculation in the UseSyncMethodIntercepter got me further, but it's clear this is going to require more thought and careful evaluation. I have a scenario where this would be handy, but will just work around this for now by using WaitUntil.Started in non-SNIPPET code and disable recordings while I wait - perhaps something akin to what @m-nash suggested in Azure/azure-sdk-tools#2703.

@heaths do you think there is value in exploring a solution here?

Yes. For sync-only tests that use LROs, we need a way to make sure they are runnable.

authors: JoshLove-msft heaths pallavit


text:
Visual Studio 2017 Azure Mobile Apps Table Controller Scaffold Error

I have created a .NET Mobile App Backend by following the guide as shown here. This worked wihout a problem in Visual Studio 2015, but once I loaded the project in Visual Studio 2017, I had the following issue:

Right-click on the Controllers folder and select Add > Controller....

Select the Azure Mobile Apps Table Controller option, then click Add

Visual Studio give me the following error, and I think it's a problem with the new SDK in VS 2017, but I'm not entirely sure:

The specific error is 'A TwoWay or OneWayToSource binding cannot work on the read-only property 'EntityTypes' or type 'Microsoft.Cct.MobileApps.WebExtensions.Scaffolding.MobileAppsTableViewControllerViewModel'.

@scout208 this feature is not hosted on this particular repo (azure sdk repo)
Please go to the below website and ask question
https://azure.microsoft.com/en-us/support/forums/


text:
[BUG] TableClient.CreateIfNotExistsAsync creates entry for failed request in Application Insights if table already exists

Library name and version
Azure.Data.Tables 12.6.1
Describe the bug
If I call TableClient.CreateIfNotExistsAsync() for an existing table, a request is sent to create it and the resulting exception is caught and dismissed.
Expected behavior
The call to the table storage to create the table is not logged by Application Insights as a failed request.
Actual behavior
The failed call to the table storage should not be logged by Application Insights, because it is expected and dealt with.
At least, there should be an option to turn on this behavior.
Reproduction Steps
var tableServiceClient = new TableServiceClient(connectionString);
var tableClient = tableServiceClient.GetTableClient(tableName);
await tableClient.CreateIfNotExistsAsync();
Environment
Azure App Service, Linux x64, .NET 6

Hi @thomasneubergersdx.  Thank you for reaching out and we regret that you're experiencing difficulties.   This is a known behavior of the Storage library, and one that a fix is planned for.   This work is tracked under #9934.    I'm going to link this to that issue and close out as a duplicate.

authors: jsquire thomasneubergersdx


text:
[BUG] KustoDatabaseCollection CreateOrUpdateAsync returning ResourceNotFound - false failure

Library name and version
Azure.ResourceManager.Kusto 1.3.0
Describe the bug
when calling the KustoDatabaseCollection.CreateOrUpdateAsync  with WaitUntil.Completed we are getting this exception:
The resource with identifier '/subscriptions/**/resourceGroups/**/providers/Microsoft.Kusto/Clusters/**/Databases/**' is not found.
Status: 404 (Not Found)
ErrorCode: ResourceNotFound
at Azure.Core.OperationInternal1.GetResponseFromState(OperationState1 state)
at Azure.Core.OperationInternal1.<UpdateStatusAsync>d__20.MoveNext()    at System.Threading.Tasks.ValueTask1.get_Result()
at Azure.Core.OperationInternalBase.d__13.MoveNext()
at System.Threading.Tasks.ValueTask1.get_Result()    at Azure.Core.OperationPoller.<WaitForCompletionAsync>d__11.MoveNext()    at System.Threading.Tasks.ValueTask1.get_Result()
at Azure.Core.OperationInternalBase.d__19.MoveNext()
at System.Threading.Tasks.ValueTask1.get_Result()    at Azure.Core.OperationInternal1.d__19.MoveNext()
at System.Threading.Tasks.ValueTask1.get_Result()    at Azure.Core.OperationInternal1.d__15.MoveNext()
at System.Threading.Tasks.ValueTask`1.get_Result()
at Azure.ResourceManager.Kusto.KustoDatabaseCollection.d__7.MoveNext()
but after waiting 1 minute, the database was actually successfully created!
Expected behavior
when WaitUntil.Completed is provided, the operation is expected to be awaited until the long-running operation has completed without unexpected errors.
Actual behavior
exception is thrown, but the operation is actually succeeded after waiting up to one additional minute.
Reproduction Steps
initialize ArmClient with token credentials and define the cluster resource identifier then :
var kustoClusterResource = new ArmClient(tokenCredentials).GetKustoClusterResource(clusterResourceIdentifier);   await kustoClusterResource.GetKustoDatabases().CreateOrUpdateAsync(WaitUntil.Completed,databaseName,databaseData);
Environment
No response

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

@jsquire @ArthurMa1978 , Any updates?
Thanks!

I am experiencing the exact same issue where an exception of "not found" is always thrown when attempting to create a Kusto database. However, upon retrying (after couple of minutes) the creation process, it eventually succeeds. Therefore, I fully concur with @adelKhatib 's assertion that WaitUntil.Completed does not function as anticipated. @ArthurMa1978 , what is your opinion on this matter? This issue is currently preventing me from proceeding with the release. @jsquire

Thank you for your feedback, we're working on it.

We have a test to cover Kusto database creation, it works as expected. And also, I tried to create a Kusto database lively, it works as expected as well.
@adelKhatib Does this happen randomly?
@msSameerEd As you mentioned it always returns 404 and succeeded after waiting for some time, did you try to create a new database after the waiting? Then, it seems random failure from server side, not SDK error.

@live1206 , this happen consistently on the first try, the issue is obviously related to the status polling, the exception of “Not found” prevent the thread from waiting until completion of the creation, despite that the creation process is still in progress.
Can you please try to create a database (lively) with a name that you never tried.

@live1206 , this happen consistently on the first try, the issue is obviously related to the status polling, the exception of “Not found” prevent the thread from waiting until completion of the creation, despite that the creation process is still in progress. Can you please try to create a database (lively) with a name that you never tried.

@adelKhatib I don't think it always returns 404 on the first try since I managed to create a Kusto database with the SDK. And as I mentioned there is an existing test for this case successfully running. With the recorded service response in place, the test could pass with SDK.
I tried to create a database for 4 times, always got 200
            var db = await Cluster.GetKustoDatabases().CreateOrUpdateAsync(WaitUntil.Completed, databaseName, databaseDataCreate);
            var response = db.GetRawResponse();

the issue is obviously related to the status polling

This is not accurate, the implementation for long-running operations is generated by autorest.csharp, the status polling mechanism is the same for all services & operations.
Please let me know if I am missing any information from you to reproduce this error.

@adelKhatib As offline discussed, please try to get the traffic log of service response while you get 404 during creation, so that we can figure out the next step.

The root cause is from service response.
LRO is working like this:

Keep polling to get completed status of the operation
Get the created resource

From the log of @adelKhatib, it keeps polling of the operation status until it's completed.
And when it tries to get the created database back, it returns 404 from server side, which is not expected.

@live1206, @ilayrn, and @orhasban, I am experiencing a persistent issue that is incredibly frustrating. This problem has caused a significant delay in implementing a crucial feature in my project, and I am counting on your prompt assistance in resolving it. I would greatly appreciate it if you could resolve this matter as soon as possible.
@live1206 , regarding your last response, I'm a bit confused about what you mean by 'server side', which team is responsible for it?, Can you explain? Also, any ideas on how I can figure out what's going on with this issue? Like, can I get some log traces or something? By the way, do you know of any quick fixes to help me deal with this?

Hi everyone,
This was an error on the Kusto backend side (unrelated to c# SDK client)
Mostly affecting internal Microsoft consumers.
We are deploying a HF  by the end of the week, fixing the issue


text:
[QUERY] Interactive Browser Change with Version 1.10 of Azure.Identity

Library name and version
Azure.identity 1.10
Query/Question
Version 1.9 was able to use interactive browser credentials and cache the authorization record.
Version 1.10 asks to re-enter the password every time.
'--------------------------------------------------------
'Application Code:
'--------------------------------------------------------
'// Load the previously serialized AuthenticationRecord from disk And deserialize it.
Using authRecordStream = New IO.FileStream(AuthFile_Name_and_Path, IO.FileMode.Open, IO.FileAccess.Read)
    'authRecord = await Azure.Identity.AuthenticationRecord.DeserializeAsync(authRecordStream)
    _auth = Azure.Identity.AuthenticationRecord.Deserialize(authRecordStream)
End Using

'// Construct a New client with our TokenCachePersistenceOptions with the addition of the AuthenticationRecord property.
'// This tells the credential to use the same token cache in addition to which account to try And fetch from cache when GetToken Is called.
Dim _tcpo As New Azure.Identity.TokenCachePersistenceOptions
_tcpo.Name = TOKEN_CACHE_NAME
Dim _ibcredopts As New Azure.Identity.InteractiveBrowserCredentialOptions
_ibcredopts.TokenCachePersistenceOptions = _tcpo
_ibcredopts.AuthenticationRecord = _auth

'Dim _bcos As New Identity.BrowserCustomizationOptions
'_bcos.UseEmbeddedWebView = True 'False use Chrome, True used built in
'_ibcredopts.BrowserCustomization = _bcos

_ibc = New Azure.Identity.InteractiveBrowserCredential(_ibcredopts)
Dim _TokenReqContext = New Core.TokenRequestContext(New String() {"https://batch.core.windows.net" & "/.default"})

'*******************************************************************************************************
'PROBLEM
'*******************************************************************************************************
Dim _AccessToken As Core.AccessToken = _ibc.GetToken(_TokenReqContext, Nothing) '==Version 10 causes browser window to open every time now
'*******************************************************************************************************

Environment
.Net Framework 4.8

I see that the cache file name now gets a .cae or .nocae on the end with version 10. Do we have to program for that?

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

This is a bug - we should have a fix available soon. Sorry for the inconvenience!

No problem! It's nice to know we might know what we are doing.

As a side note - the silent auth should work after the first GetToken request. The bug is that we don't properly recognize that the cache is already populated on a new instance of the credential.

authors: christothes jsquire scottbright22


text:
Add additional logging for Key Vault live tests

Needed to properly diagnose and fix issue #10496.

@pakrym and @KrzysztofCwalina I think this is also a novel way of hiding more "test smells" to samples by hiding the LiveOnly and possibly NonParallelized attributes, or anything else we don't want in samples to make them feel more like tests. Thoughts?

I think the idea was that we don't care how test files look as long as snippet.mds are good.
It doesn't solve the issue of snippets looking like tests completely so not sure if the additional complexity is worth it and if we want to make this a common pattern for samples. cc @tg-msft

No, not completely but does also help hide SetUp- and TearDown-attributed methods as well as other attributes we may not want visible. The "complexity" introduced here was primarily to reduce code duplication while improving diagnostics so I can get to the bottom of sporadic test failures caused by concurrent resource contention.

Originally we talked about using source code as samples and I did a lot of massaging to make things work correctly but not look overly complicated to users stepping through things:

Nice test: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Queues/samples/Sample01a_HelloWorld.cs#L29
Ugly bits: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Queues/samples/QueuesSampleTest.cs#L15

Now that I'm just doing markdown files, I don't care as much:

Markdown: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/search/Azure.Search.Documents/samples/Sample01a_HelloWorld.md#create-a-client
Test: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/search/Azure.Search.Documents/tests/Samples/HelloWorld.cs#L24

Key Vault already does something like that prior to the new comment syntax, but I think we already do a pretty good job of keeping out the "cruft" from the markdown files. I just figured that if people were looking at the .cs files themselves, this makes them look less "testy". again, the main reason was to consolidate common code - I certainly didn't want to add duplicate code to samples making them look ever more "testy".

My main concern is consistency, I'd like all track 2 libraries to be doing as much of the same thing as possible. If we think something is worth doing we should add it to the guidelines and do everywhere.

authors: heaths pakrym tg-msft


text:
[ACS][Chat] Add File Sharing

Description
We are updating the Chat SDK for Java to include file sharing support. No logic changes on SDK side, we only updated the chat client based on latest swagger:
https://raw.githubusercontent.com/Azure/azure-rest-api-specs/f579ddcd291d55b0a2a32ee81995432458db3da9/specification/communication/data-plane/Chat/readme.md
build will fail until we deploy the new backend API.
Test
N/A since backend API isn't live yet

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Communication.Chat

authors: azure-sdk jpeng-ms


text:
DO NOT MERGE : Personalizer : Incorporate API review board changes

Personalizer : Incorporate API review board changes
Azure-rest-api-specs - https://github.com/Azure/azure-rest-api-specs/pull/5871

Please open a new PR aligning to the new directory structure

authors: dwaijam shahabhijeet


text:
azure-mgmt-web list_skus() always returns empty list from Azure Mgmt API

I'm having the exact same issue as described in this issue https://github.com/Azure/azure-sdk-for-python/issues/6671 except with azure-mgmt-web 0.48.0 where the list_skus() return empty no matter which subscription i call it with. Even trying out https://docs.microsoft.com/en-us/rest/api/appservice/list-skus/list-skus results in an empty response.

Package Name:  azure-mgmt-web
Package Version:  0.48.0
Operating System: Ubuntu 20.04
Python Version: 3.8.10

Describe the bug
The list_skus() method returns an empty response { "value": [] } no matter which subscription I call it with. Even the Rest API documentation "try it" feature returns an empty response.
Expected behavior
A list of available skus is returned.

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'App Services:0.5586482,Subscription:0.029501835,Web Apps:0.026061742'

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'App Services:0.5586482,Subscription:0.029501835,Web Apps:0.026061742'

Hi @rcampos87,thank you for your feedback.
After investigation, it is recommended that you use the latest version of azure-mgmt-web.
Read the doc linked below to help you understand how to effectively resolve issues.
fyi: https://github.com/Azure/azure-sdk-for-python/blob/main/doc/dev/issues/resolve_issues_effectively.md

@Wzb123456789 thank you for the reply, as of now we are unable to the anything past v0.48.0 because of the azure authentication method into the API, as I have seen,  for higher versions the authentication flow was changed or rewritten from the normal client_id, client_secret. The latest version of the Rest API found at https://docs.microsoft.com/en-us/rest/api/appservice/list-skus/list-skus does not work either and i assume the latest azure-mgmt-web also uses this endpoint.

Hi @rcampos87
The SDK is generated by swagger. The SDK receives and processes the data returned by the service. From the SDK's point of view, it cannot solve your problem.
It is recommended that you re-report the issue you encountered in https://github.com/Azure/azure-rest-api-specs/pulls

@rcampos87 Did you get a chance to look at the above suggestions provide by @Wzb123456789 . Please let us know if you need any further assistance on this thread. Awaiting your reply.

@navba-MSFT @Wzb123456789 thanks for the reply. I have opened a ticket with tech support for App Services that deals with Rest API, thanks for the help.

@rcampos87 Thanks for getting back. We will now proceed with closure of this github issue. If you need any further assistance on this issue in future, please feel free to reopen this thread. We would be happy to help.

repo: Azure/azure-sdk-for-python


text:
Data drop 400: 109: Field 'typeName' on type 'ExceptionDetails'

Package Name:  azure-monitor-opentelemetry-exporter
Package Version: 1.0.0b14
Operating System: debian
Python Version: 3.11

Describe the bug
A clear and concise description of what the bug is.
Every once in a while we get this error. Not sure if it's misconfigured on our end or if it's a bug.
Data drop 400: 109: Field 'typeName' on type 'ExceptionDetails' is required but missing or empty.
Expected: string
{
'additional_properties': {},
'version': 1,
'name': 'Microsoft.ApplicationInsights.Exception',
'time': '2023-12-05T14:25:51.098915Z',
'sample_rate': 100,
'sequence': None,
'instrumentation_key': '<key>',
'tags':
{
  'ai.device.id': 'e3c4d6859f04',
  'ai.device.locale': 'en_US',
  'ai.device.osVersion': '#1 SMP Wed Jun 21 23:17:09 UTC 2023',
  'ai.device.type': 'Other',
  'ai.internal.sdkVersion': 'py3.11.6:otel1.18.0:ext1.0.0b14',
  'ai.cloud.role': '<service-name>',
  'ai.cloud.roleInstance': '04d4bf52f693266441b170bf46cebd271f527fb80901df8f7ea26b618af74c76',
  'ai.internal.nodeName': '04d4bf52f693266441b170bf46cebd271f527fb80901df8f7ea26b618af74c76', 'ai.operation.id': '00000000000000000000000000000000',
  'ai.operation.parentId': '0000000000000000'
},
'data': <azure.monitor.opentelemetry.exporter._generated.models._models_py3.MonitorBase object at 0x7c869c3f00d0>}.

To Reproduce
Not sure.
Expected behavior
If typeName is empty then it should be sent with some default value, but sent.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Hi @macieyng - Thanks for opening an issue. We'll take a look asap!

@macieyng
Can you upgrade to the latest version of the exporter and see if that fixes your issue?

We have a pending upgrade for that app sometime next week, but it's 1.0.0b17 (as per https://github.com/Azure/azure-sdk-for-python/pull/32897#issuecomment-1841685887).
I reported this cause I couldn't find similar issue.

authors: lzchen macieyng swathipil


text:
T2 datadog 2021 03 02

https://github.com/Azure/sdk-release-request/issues/1314

/azp run


text:
Allow Tox Environments to be Configured As Skippable via platform-matrix

This PR also:

updates identity matrix to exclude mindependency/latestdependency checks for the MSAL run
updates an inline pshell script to a python script

/azp run python - identity - ci


text:
[AutoPR keyvault/data-plane] AKV Rest Samples

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/2873

(message created by the CI based on PR content)


text:
[AutoRelease] t2-eventgrid-2022-08-17-76927(Do not merge)

https://github.com/Azure/sdk-release-request/issues/2985
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=1031
BuildTargetingString
azure-mgmt-eventgrid
Skip.CreateApiReview
true

issue link:https://github.com/Azure/sdk-release-request/issues/2985