text:
Application Fingerprinting(BYO-repo)

Right now, we sort of leave the exercise of figuring out what services are needed to move an app to Azure up to the developer. We should be able to provide them with more of an opinionated take so that we can decrease the cognitive load. We should also do this in approachable, non-Azure language so that folks without deep background can get started.
User flow:

Run azd init in a codebase dir (non-templatized)
User is provided with a series of prompts to walkthrough and accept the "suggested" services needed to move their app to the cloud (e.g. azd sees React and so we suggest Static Web Apps), with smart defaults + configurations
At each prompt, user is provided with the opportunity to either accept the default suggestion or amend an azd-suggested service and choose another option (maybe I don't want Cosmos and actually want Azure SQL)
As a result of the command executing, the user receives all the appropriate IaC assets in their project written in Bicep to run azd up with little to no amendments

We will evaluate both an AI and non-AI powered version of this.
### Tasks
- [ ] https://github.com/Azure/azure-dev/issues/1907
- [ ] https://github.com/Azure/azure-dev/issues/1594
- [ ] https://github.com/Azure/azure-dev/issues/1260
- [ ] Prototype AI variant
- [ ] Prototype non-AI variant
- [ ] Create initial design explorations for the Golden Path scenario
- [ ] Create initial design explorations for Error and Troubleshooting scenarios

In addition to forming an opinionated infrastructure folder we should also explore generating default github actions / azdo pipeline files to help enable pipeline configuration.

@savannahostrowski @ellismg Not in scope for GA. Moving this to Gallium.

With fingerprinting, we may be able to add a subsequent feature. as @vhvb1989 suggests here:
services:
  web:
    project: ./src/web
    language: auto # may be omitted

Detecting the project file based on the folder would be fairly trivial. If we can't, we can simply emit an error.

We should also figure out how this fits in with azd init,and whether this solves the problem of azd init in current directory vs azd new in new directory etc. Original comment here

07/07/2023 | End of week design update
This week

Created initial Application Fingerprinting golden path prototype in Figma
Reviewed prototype with @savannahostrowski
Reviewed prototype with design team during crit and captured feedback

Next week

Present Golden Path scenario prototype during team demo time (cc: @rajeshkamal5050)
Incorporate feedback from design crit and team demo
Create initial flow explorations for language detection failure and DB config [See blocker below]

Blockers
Unable to create designs for the incorrect language detection, DB configuration, and other edge-case scenarios until we have a better understanding of how the language detection will work and how accurate it will be (cc: @weikanglim)
Team, feel free to comment here or in the prototype linked above if you have feedback, thoughts, or concerns

Other scenarios to prioritize for Ignite:

Support for Dockerfiles - today, we are leveraging buildpacks when targeting ACA. We should also allow a developer to define their own Dockerfile
Managed add-ons - Running Redis in a container on ACA is faster to provision. We should lean on managed add-ons where possible

Closing this for now in favour of smaller items. Will discuss with @weikanglim

authors: Austinauth rajeshkamal5050 savannahostrowski wbreza weikanglim

repo: Azure/azure-dev


text:
Publish content from master

Manual promotion of content from master branch to live branch.

@rloutlaw,
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

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

2017-03-09-profile/docs-ref-autogen/TOC.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/account.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/acr.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/acr/credential.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/acr/repository.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/acr/webhook.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/acs.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/acs/dcos.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/acs/kubernetes.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/ad.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/ad/app.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/ad/group.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/ad/group/member.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/ad/sp.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/ad/user.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/appservice.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/appservice/plan.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/account.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/account/autostorage-keys.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/account/keys.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/application.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/application/package.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/application/summary.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/certificate.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/job-schedule.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/job.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/job/all-statistics.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/job/prep-release-status.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/location.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/location/quotas.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/node.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/node/file.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/node/remote-desktop.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/node/remote-login-settings.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/node/scheduling.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/node/user.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/pool.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/pool/all-statistics.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/pool/autoscale.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/pool/node-agent-skus.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/pool/os.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/pool/usage-metrics.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/task.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/task/file.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/batch/task/subtask.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/billing.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/billing/invoice.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/billing/period.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

backing out PR

source: gharchive/pull-request

authors: formulahendry msftclas rloutlaw

repo: Azure/azure-docs-cli-python

license_type: permissive

license_source: github-api


text:
Disabled app restart in container

Having the container restart on application failure is convenient while developing locally. However, on an actual deployment, it'd be better for failures to be handled by the container orchestrator (like Kubernetes) and have that decide whether the application should be restarted.

 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: fhalim sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: fhalim msftclas

repo: Azure/azure-functions-docker

license: MIT


text:
HttpRequestData Body property throws an error if missing

Seems like it would be better if HttpRequestData.Body was set to Null instead of throwing NullReferenceException when it's not in a request...
Example:
using System.Collections.Generic;
using System.Net;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Pipeline;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace FunctionApp
{
    public static class Function4
    {

        [FunctionName("Function4")]
        public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequestData req,
            FunctionExecutionContext executionContext)
        {
            var logger = executionContext.Logger;

            // This throws a NullReferenceException so a try/catch is needed to check for a missing Body
            if (req.Body == null)
            {
            }

            logger.LogInformation("message logged");
            var response = new HttpResponseData(HttpStatusCode.OK);
            var headers = new Dictionary<string, string>();
            headers.Add("Date", "Mon, 18 Jul 2016 16:06:00 GMT");
            headers.Add("Content", "Content - Type: text / html; charset = utf - 8");

            response.Headers = headers;
            response.Body = "Welcome to .NET 5!!";

            return response;
        }
    }

}

Hi @BroMarduk please check this one
The  HttpRequestData was changed in the latest preview4 version. So probably this issue is no longer exists. Please check the Function5 example to see how to work with HttpRequestData

Yes, this works as expected now with preview 4
string body = req.Body.HasValue ? Encoding.UTF8.GetString(req.Body.Value.Span) : string.Empty;

source: gharchive/issue

authors: BroMarduk alexanderbikk


text:
[ASP.NET Core Integration] Skip serialization of http response following function execution

HTTP responses should not go through the following code path:
https://github.com/Azure/azure-functions-dotnet-worker/blob/cf06831697fbcd7cb16157d65b737e5a97572dab/src/DotNetWorker.Grpc/RpcExtensions.cs#L21
These extra steps are unnecessary and impact performance.

This issue may also be causing a race condition bug: #2682

Closing as this is done for HttpResponseData when it is set in InvocationResult, and the item tracking multi-output responses is #2682

repo: Azure/azure-functions-dotnet-worker


text:
Please add Azure Web PubSub to the functions extension bundle.

Azure Web PubSub (currently in preview) has Azure function triggers, input/output bindings.
Currently, Microsoft.Azure.WebJobs.Extensions.WebPubSub is not a part of the functions extension bundle and I'm forced to register it separately.
func extensions install --package Microsoft.Azure.WebJobs.Extensions.WebPubSub --version 1.0.0-beta.3

Would it be possible to add this package to the extension bundle?
Edit: Submitted PR #108 to address this issue. Can someone please take a look?

PR merged.

authors: fabiocav mithunshanbhag

repo: Azure/azure-functions-extension-bundles


text:
Output binding not allowing SslCaLocation property value to be injected from a settings file

Hi all,
My team and I have encountered an issue when trying to use a setting placeholder for the certificate location when configuring the output binding like so:

And this is the error we receive when attempting to produce the message:

It only works by hard-coding the path. This is not case with the trigger binding. Am I correct to assume this is an issue and not intended?
Regards, Milos
Software Developer

@milos-miric thanks for raising the issue, could you please this without % and entering the path in host.json ?

Thanks for responding @shrohilla , sadly removing the '%' prints the same error, same with entering the path to local.settings.json

This issue is duplicate of #202

authors: milos-miric sapinderpalsingh shrohilla

repo: Azure/azure-functions-kafka-extension


text:
Update quickstart to support futures/Android Studio

In our private branch, update the quickstart: https://github.com/Azure/azure-mobile-services/tree/master/quickstart/android/ZUMOAPPNAME to support futures and Android Studio. I've already done most of the work here: https://github.com/yavorg/samples/tree/master/AndroidStarter

@aziel is looking at the commit at https://github.com/ysxu/azure-mobile-services/commit/315b030e739279b029cbf390c5bc22045b1ead74 and I will submit a pull request then close this item if all looks fine by tomorrow.

Quickstart updated at https://github.com/Azure/azure-mobile-services/pull/590

authors: yavorg ysxu

repo: Azure/azure-mobile-services

license_source: bigquery


text:
fix(HttpClient): Removing Apache HttpClient in favor of HttpURLConnection

fix(HttpClient): Removing Apache HttpClient in favor of HttpURLConnection
This PR addresses the Azure Documentation Issue 14718 to remove the deprecated Apache HttpClient in favor of HttpURLConnection class.

 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: mattpodwysocki sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Fixes #46

authors: mattpodwysocki msftclas stankovski

repo: Azure/azure-notificationhubs


text:
Swagger spec for microsoft.web/connections is missing

microsoft.web/connections isn't included in the views.

Thank you bring this to our attention!
@naveedaz, what do you think about this?

Unfortunately Microsoft.Web/connections is internally managed by the Resource Manager team, so it does not generate with our swagger file. I am working with them to figure out a feasible solution.

Hi @naveedaz
Can we kindly get an update on your discussion with the Web/Connections taeam?

close legacy issue.

authors: devigned kevinlam1 naveedaz salameer yungezz

repo: Azure/azure-rest-api-specs


text:
[Resources] Response from Azure Stack doesn't comply with the spec subscriptions.json

When using 2019-06-01 with Azure Stack to get subscriptions (in this case management.redmond.azurestack.corp.microsoft.com), the response doesn't comply with the REST spec subscriptions.json. For example, authorizationSource and  managedByTenants are missing from the response.
https://github.com/Azure/azure-rest-api-specs/blob/76b6bd1989a8248987219b840f525b02e07807dc/specification/resources/resource-manager/Microsoft.Resources/stable/2019-06-01/subscriptions.json#L271-L277
> az cloud register -n redmond --endpoint-resource-manager "https://management.redmond.azurestack.corp.microsoft.com/"
> az cloud set -n redmond
> az login --debug

msrest.http_logger : Request URL: 'https://management.redmond.azurestack.corp.microsoft.com/subscriptions?api-version=2019-06-01'
msrest.http_logger : Request method: 'GET'

msrest.http_logger : Response status: 200
msrest.http_logger : Response content:
msrest.http_logger :
{
    "value": [
        {
            "offerId": "/delegatedProviders/default/offers/full-offer",
            "id": "/subscriptions/c9b8dfff-aff0-49b5-93bd-a1581f1896a0",
            "subscriptionId": "c9b8dfff-aff0-49b5-93bd-a1581f1896a0",
            "tenantId": "81cfafcd-8b9a-4419-9c85-823b54076b55",
            "displayName": "azclidevtools",
            "state": "Enabled",
            "subscriptionPolicies": {
                "locationPlacementId": "AzureStack"
            }
        }
    ]
}

This causes failure in Azure CLI when retrieving managed_by_tenants:
  File "C:\Users\jiasli\AppData\Local\Programs\Python\Python38\lib\site-packages\azure\cli\core\_profile.py", line 276, in _normalize_properties
    subscription_dict[_MANAGED_BY_TENANTS] = [{_TENANT_ID: t.tenant_id} for t in s.managed_by_tenants]
TypeError: 'NoneType' object is not iterable

The response of the public AzureCloud is:
> az cloud set -n AzureCloud
> az login --debug

msrest.http_logger : Request URL: 'https://management.azure.com/subscriptions?api-version=2019-06-01'
msrest.http_logger : Request method: 'GET'

msrest.http_logger : Response status: 200
msrest.http_logger : Response content:
msrest.http_logger :
{
    "value": [
        {
            "id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590",
            "authorizationSource": "RoleBased",
            "managedByTenants": [
                {
                    "tenantId": "2f4a9838-26b7-47ee-be60-ccc1fdec5953"
                }
            ],
            "subscriptionId": "0b1f6471-1bf0-4dda-aec3-cb9272f09590",
            "tenantId": "54826b22-38d6-4fb2-bad9-b7b93a3e9c5a",
            "displayName": "AzureSDKTest",
            "state": "Enabled",
            "subscriptionPolicies": {
                "locationPlacementId": "Internal_2014-09-01",
                "quotaId": "Internal_2014-09-01",
                "spendingLimit": "Off"
            }
        }
    ],
    "count": {
        "type": "Total",
        "value": 1
    }
}

If 2019-06-01 is not supported, the service should return "unsupported API version" instead a wrong response which doesn't comply with the spec.

Azure Stack Resources

@jiasli I think we should be able unblock with the API Profile setting for azurestack consuming a older version. Please let me know if this issue is blocking you

Actually the api version 2019-06-01 is not supported and azurestack should return Not Supported error for the call. It is not happening right now. We will fix it

Thanks @bganapa, using an old API does solve the issue. But you are right:

Azure Stack should return Not Supported error for the call.

@jiasli WE have ainternal trackign item for the Not Supported return issue. Can we close this issue?

I noticed this issue is still not fixed yet. When will this be deployed?

authors: bganapa jiasli yonzhan


text:
[Hub Generated] Review request for Microsoft.ResourceGraph to add version preview/2021-06-01-preview

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Latest improvements:

### Contribution checklist:
- [ ] I have reviewed the [documentation](https://github.com/Azure/adx-documentation-pr/wiki/Overall-basic-flow) for the workflow.
- [ ] [Validation tools](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md#validation-tools-for-swagger-checklist) were run on swagger spec(s) and have all been fixed in this PR.
- [x] The [OpenAPI Hub](https://aka.ms/openapiportal) 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.

/azp run

@PhoenixHe-msft Is there anything you need from me on this PR?

The ConstraintChanged are matching the constraints that are in the stable version for these same properties.
For the RemovedProperty we are bringing forward the same change that was done as part of #13380 when this was considered a warning and not an error.
DefaultValueChanged is also using the same default value as the latest stable version where it changed.

@johnthcall ARM review is required for new api version

Reviewed the version changes from ARM perspective. Marking ARMSignedOff.

authors: PhoenixHe-msft chiragg4u johnthcall


text:
Minor Fixes for TrafficController 2022-10-01-preview

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
[x] 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"
[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.

Breaking change due to enum value changes. RP is first release and in private preview. Breaking change signed off.

authors: allenjzhang malpaniHMC


text:
Add RP open API specs Microsoft.AgriculturePlatform version 2024-06-01-preview to public repo

…1-preview to public repo
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.
[ ] 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.
[ ] Convert existing OpenAPI spec to TypeSpec spec (do not combine this with implementing changes for a new API version).
[ ] 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

 Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated 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.

Moving to public repo.
PR merged in private repo RPSaaSMaster branch - https://github.com/Azure/azure-rest-api-specs-pr/pull/18659

Signing off based on the private repo PR

@raosuhas could you also approve and merge?

@raosuhas can you please merge this PR?

authors: pratyush-prateek raosuhas


text:
Search SDK: Modifying description of DataContainer.query

It now takes into account the existence of new datasource types.
FYI @chaosrealm

lgtm

No modification for Python

No modification for NodeJS

authors: AutorestCI brjohnstmsft chaosrealm


text:
Added patch API to swagger doc in Visual studio RP

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-go

Automation for azure-sdk-for-python

Automation for azure-sdk-for-node

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

Automation for azure-sdk-for-js

Automation for azure-sdk-for-java

Can one of the admins verify this patch?

authors: AutorestCI azuresdkci deepakabburi


text:
Add data plane API swagger for attestation

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.

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

hi @shleiAmy could you pls fix CI failure while waiting for API review board reviewing?

@yungezz @LarryOsterman I have resubmit the pr which should fix the ModelValidation error and LintDiff failed error.
But for the LintDiff error, I don't understand why the data plane APIs need to meet the Arm Specs
R3023 - OperationsAPIImplementation
Operations API must be implemented for '/providers//operations'.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:26
R3013 - DeleteMustNotHaveRequestBody
'Delete' operation 'Policy_Delete' must not have a request body.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:222

test

@yungezz @LarryOsterman
I have resubmit the pr which should fix the ModelValidation error and LintDiff failed error.
But for the LintDiff error, I don't understand why the data plane APIs need to meet the Arm Specs:
R3023 - OperationsAPIImplementation
Operations API must be implemented for '/providers//operations'.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:26
R3013 - DeleteMustNotHaveRequestBody
'Delete' operation 'Policy_Delete' must not have a request body.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:222

HI @shleiAmy they're all rest api. If you have some exception, can discuss it with reviewing board. To ignore the validation errors.

@yungezz
The pr is marked as WaitingForAzureAPIBoard  for a couple of days.
But I was told by Azure Resource Manager RP API review team that they don't handle data plane reviews. and those data plane reviews are handled by azureapirbcore
I tried to send an email to azureapirbcore, but got rejection from this email address.
Could you please forward this pr to the correct team to next step review?
because We are waiting to finalize the swagger, then publish SDK, and complete powershell/cli cmdlets to meet our public preview deadline.
Thanks.

@yungezz
The pr is marked as WaitingForAzureAPIBoard for a couple of days.
But I was told by Azure Resource Manager RP API review team that they don't handle data plane reviews. and those data plane reviews are handled by azureapirbcore
I tried to send an email to azureapirbcore, but got rejection from this email address.
Could you please forward this pr to the correct team to next step review?
because We are waiting to finalize the swagger, then publish SDK, and complete powershell/cli cmdlets to meet our public preview deadline.
Thanks.

hi @shleiAmy, I've sent email to review board several days ago, you're in the email also, title "pls help to review PR https://github.com/Azure/azure-rest-api-specs/pull/7521". you'll share more in the thread about service schedule for ping for reviewing.

meanwhile, pls fix CI failure to be prepared.

@yungezz
The CI fails for the ARM errors:
R3023 - OperationsAPIImplementation
Operations API must be implemented for '/providers//operations'.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:26
R3013 - DeleteMustNotHaveRequestBody
'Delete' operation 'Policy_Delete' must not have a request body.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:218
This is the data plane API, why it need to meet the ARM specs?

hi @shleiAmy are all comments addressed? Is the PR ready for reviewing again?

@yungezz yes, the pr is waiting for review again
Thanks

Hi @shleiAmy  pls fixing LintDiff CI failure.
hi @johanste could you pls review the PR again?

@yungezz As I mentioned on Oct 25
The CI fails for the ARM errors:
R3023 - OperationsAPIImplementation
Operations API must be implemented for '/providers//operations'.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:26
R3013 - DeleteMustNotHaveRequestBody
'Delete' operation 'Policy_Delete' must not have a request body.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:218
This is the data plane APIs, why it needs to meet the ARM specs?
Is there any Azure API design guidelines that we should follow?
If I have to fix the CI failure, then the Policy_Delete should not have a request body.
I add @LarryOsterman for this dicussion.

@yungezz The CI fails for two errors:
R3023 - OperationsAPIImplementation
Operations API must be implemented for '/providers//operations'.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:26
R3013 - DeleteMustNotHaveRequestBody
'Delete' operation 'Policy_Delete' must not have a request body.
at specification/attestation/data-plane/Microsoft.Attestation/preview/2018-09-01-preview/attestation.json:218
I just change the Route from
"operations/policy/current" ->policy/current"
"operations/policy/updatepolicy"->"policy/updatepolicy"
to get rid of the keywords "operations".
however, the CI still fails for the same error
I don't know why it keeps on complaining Operations API must be implemented for '/providers//operations'.
@johanste we have explained why we need a request body in delete operation. And haven't heard back from you since Nov 4th.

pending on review board comments.

approved in azureapirb

/azp run automation - sdk

@yungezz I have fixed the failure for required CI check. And also I see this or is approved by azure api group. Could you please take some time to review this pr ? I am waiting for the data plane swagger to publish and then work on publishing SDK, poweshell and cli cmdlets.And I am blocked by this pr.  Thanks.

approved in azureapirb

HI @rysweet  could you pls label the PR "AzureAPIBoardSignedOff"? then we'll go ahead to merge this PR. thanks.

authors: AutorestCI azuresdkci rysweet shleiAmy yungezz


text:
[Hub Generated] Review request for Microsoft.Maintenance to add version preview/2018-06-01-preview

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.

/azp run automation - sdk

Can one of the admins verify this patch?

authors: AutorestCI azuresdkci gautamd-ms


text:
[DoNotMerge] Compute 2020-06-01 API version update

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. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
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.

/azp run automation - sdk

/azp run automation - sdk

Can one of the admins verify this patch?

/azp run automation - sdk

/azp run automation - sdk

authors: AutorestCI azuresdkci hyonholee


text:
Sample for fetchContent

fixes: #1387

From the issue:

Once the app is ready, use it from CI to test that the SDK can be consumed by end users by this approach without any issues.

Should we wait to close the issue until this part is done too? Are you planning to add the CI update to this PR as well?

From the issue:

Once the app is ready, use it from CI to test that the SDK can be consumed by end users by this approach without any issues.

Should we wait to close the issue until this part is done too? Are you planning to add the CI update to this PR as well?

Sharing results from trying this sample app with the latest Azure SDK releases:
Linux
Release Storage 12.0 beta.6.0
CMake Generate: Ok
Building: Ok
Running: Ok
Release Storage 12.0 beta.5.0
CMake Generate: Failed, then OK with Workaround
unknown Azure::azure-storage-blobs for linking. Need to use azure-storage-blobs
CMake Error at /home/vivazqu/workspace/vcpkg/scripts/buildsystems/vcpkg.cmake:418 (_add_executable):
  Target "application" links to target "Azure::azure-storage-blobs" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

Building: Failed.
Fail during app build/link
Scanning dependencies of target application
[ 97%] Building CXX object CMakeFiles/application.dir/src/main.cpp.o
In file included from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/credentials.hpp:12:0,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/identity/azure-identity/inc/azure/identity/client_secret_credential.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs/append_blob_client.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:12:
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: error: ‘CurlTransport’ is not a member of ‘Azure::Core::Http’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^~~~~~~~~~~~~
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: note: suggested alternative: ‘HttpTransport’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^~~~~~~~~~~~~
                                                                                HttpTransport
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: error: ‘CurlTransport’ is not a member of ‘Azure::Core::Http’
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: note: suggested alternative: ‘HttpTransport’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^~~~~~~~~~~~~
                                                                                HttpTransport
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:99: error: no matching function for call to ‘make_shared<<expression error> >()’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^
In file included from /usr/include/c++/7/memory:81:0,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/context.hpp:13,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/credentials.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/identity/azure-identity/inc/azure/identity/client_secret_credential.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs/append_blob_client.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:12:
/usr/include/c++/7/bits/shared_ptr.h:703:5: note: candidate: template<class _Tp, class ... _Args> std::shared_ptr<_Tp> std::make_shared(_Args&& ...)
     make_shared(_Args&&... __args)
     ^~~~~~~~~~~
/usr/include/c++/7/bits/shared_ptr.h:703:5: note:   template argument deduction/substitution failed:
In file included from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/credentials.hpp:12:0,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/identity/azure-identity/inc/azure/identity/client_secret_credential.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs/append_blob_client.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:12:
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:99: error: template argument 1 is invalid
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp: In function ‘int main(int, char**)’:
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:31:21: error: ‘class Azure::Storage::Blobs::BlobContainerClient’ has no member named ‘CreateIfNotExists’
     containerClient.CreateIfNotExists();
                     ^~~~~~~~~~~~~~~~~
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:35:37: error: ‘class Azure::Storage::Blobs::BlobContainerClient’ has no member named ‘ListBlobsSinglePage’; did you mean ‘ListBlobsFlatSegment’?
     auto response = containerClient.ListBlobsSinglePage();
                                     ^~~~~~~~~~~~~~~~~~~
                                     ListBlobsFlatSegment
CMakeFiles/application.dir/build.make:62: recipe for target 'CMakeFiles/application.dir/src/main.cpp.o' failed
make[2]: *** [CMakeFiles/application.dir/src/main.cpp.o] Error 1
CMakeFiles/Makefile2:80: recipe for target 'CMakeFiles/application.dir/all' failed
make[1]: *** [CMakeFiles/application.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Running: Not possible
Release Storage 1.0 beta.4.0
CMake Generate: Ok (Need to use version 1.0 instead of 12, expected)
Building: Failed
The Application contains expected breaking changes:

#include "azure/storage/blobs/blob.hpp"
containerClient.CreateIfNotExists();
ListBlobsSinglePage()

It can build and run after fixing the breaking changes.
Running: Ok after fixing breaking changes

Sharing results from trying this sample app with the latest Azure SDK releases:
Linux
Release Storage 12.0 beta.6.0
CMake Generate: Ok
Building: Ok
Running: Ok
Release Storage 12.0 beta.5.0
CMake Generate: Failed, then OK with Workaround
unknown Azure::azure-storage-blobs for linking. Need to use azure-storage-blobs
CMake Error at /home/vivazqu/workspace/vcpkg/scripts/buildsystems/vcpkg.cmake:418 (_add_executable):
  Target "application" links to target "Azure::azure-storage-blobs" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

Building: Failed.
Fail during app build/link
Scanning dependencies of target application
[ 97%] Building CXX object CMakeFiles/application.dir/src/main.cpp.o
In file included from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/credentials.hpp:12:0,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/identity/azure-identity/inc/azure/identity/client_secret_credential.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs/append_blob_client.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:12:
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: error: ‘CurlTransport’ is not a member of ‘Azure::Core::Http’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^~~~~~~~~~~~~
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: note: suggested alternative: ‘HttpTransport’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^~~~~~~~~~~~~
                                                                                HttpTransport
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: error: ‘CurlTransport’ is not a member of ‘Azure::Core::Http’
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:84: note: suggested alternative: ‘HttpTransport’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^~~~~~~~~~~~~
                                                                                HttpTransport
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:99: error: no matching function for call to ‘make_shared<<expression error> >()’
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^
In file included from /usr/include/c++/7/memory:81:0,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/context.hpp:13,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/credentials.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/identity/azure-identity/inc/azure/identity/client_secret_credential.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs/append_blob_client.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:12:
/usr/include/c++/7/bits/shared_ptr.h:703:5: note: candidate: template<class _Tp, class ... _Args> std::shared_ptr<_Tp> std::make_shared(_Args&& ...)
     make_shared(_Args&&... __args)
     ^~~~~~~~~~~
/usr/include/c++/7/bits/shared_ptr.h:703:5: note:   template argument deduction/substitution failed:
In file included from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/credentials.hpp:12:0,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/identity/azure-identity/inc/azure/identity/client_secret_credential.hpp:11,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs/append_blob_client.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/storage/azure-storage-blobs/inc/azure/storage/blobs.hpp:6,
                 from /home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:12:
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/build/_deps/azuresdkforcpp-src/sdk/core/azure-core/inc/azure/core/http/policy.hpp:122:99: error: template argument 1 is invalid
     std::shared_ptr<HttpTransport> Transport = std::make_shared<Azure::Core::Http::CurlTransport>();
                                                                                ^
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp: In function ‘int main(int, char**)’:
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:31:21: error: ‘class Azure::Storage::Blobs::BlobContainerClient’ has no member named ‘CreateIfNotExists’
     containerClient.CreateIfNotExists();
                     ^~~~~~~~~~~~~~~~~
/home/vivazqu/workspace/azure-sdk-for-cpp/samples/Integration/CMake-fetch-content-app/src/main.cpp:35:37: error: ‘class Azure::Storage::Blobs::BlobContainerClient’ has no member named ‘ListBlobsSinglePage’; did you mean ‘ListBlobsFlatSegment’?
     auto response = containerClient.ListBlobsSinglePage();
                                     ^~~~~~~~~~~~~~~~~~~
                                     ListBlobsFlatSegment
CMakeFiles/application.dir/build.make:62: recipe for target 'CMakeFiles/application.dir/src/main.cpp.o' failed
make[2]: *** [CMakeFiles/application.dir/src/main.cpp.o] Error 1
CMakeFiles/Makefile2:80: recipe for target 'CMakeFiles/application.dir/all' failed
make[1]: *** [CMakeFiles/application.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Running: Not possible
Release Storage 1.0 beta.4.0
CMake Generate: Ok (Need to use version 1.0 instead of 12, expected)
Building: Failed
The Application contains expected breaking changes:

#include "azure/storage/blobs/blob.hpp"
containerClient.CreateIfNotExists();
ListBlobsSinglePage()

It can build and run after fixing the breaking changes.
Running: Ok after fixing breaking changes

/check-enforcer  override

/check-enforcer  override

From the issue:

Once the app is ready, use it from CI to test that the SDK can be consumed by end users by this approach without any issues.

Should we wait to close the issue until this part is done too? Are you planning to add the CI update to this PR as well?

Talked to @danieljurek .  For this type of tests we need to define how devOps would handle it.  For now, I will merge this and follow up with engSys for the CI/Pipelines integration

From the issue:

Once the app is ready, use it from CI to test that the SDK can be consumed by end users by this approach without any issues.

Should we wait to close the issue until this part is done too? Are you planning to add the CI update to this PR as well?

Talked to @danieljurek .  For this type of tests we need to define how devOps would handle it.  For now, I will merge this and follow up with engSys for the CI/Pipelines integration

/check-enforcer override

/check-enforcer override

repo: Azure/azure-sdk-for-cpp


text:
Add support of setting CAPath and relevant test

https://github.com/Azure/azure-sdk-for-cpp/issues/4983
Pull Request Checklist
Please leverage this checklist as a reminder to address commonly occurring feedback when submitting a pull request to make sure your PR can be reviewed quickly:
See the detailed list in the contributing guide.

[x] C++ Guidelines
[x] Doxygen docs
[x] Unit tests
[x] No unwanted commits/changes
[x] Descriptive title/description

[x] PR is single purpose
[x] Related issue listed

[x] Comments in source
[x] No typos
[x] Update changelog
[x] Not work-in-progress
[x] External references or docs updated
[x] Self review of PR done
[x] Any breaking changes?

@microsoft-github-policy-service agree [company="Man Group"]

@microsoft-github-policy-service agree company="Man Group"

Documentation (https://curl.se/libcurl/c/CURLOPT_CAPATH.html) says, it is not supported on Windows.
But we compile it as if it is only supported on Linux, is that the intent?
I.e. it is not supported on macOS as well, correct?

@antkmsft Yes only Linux is support.
libcurl on Mac is backed by NSS, which does not support CAPATH. CURLE_NOT_BUILT_IN will be returned runtime if trying to do so.

It seems discussions are settled and comments are addressed as well.
I will appreciate an approval if it looks good to the team. :)

@phoebusm Thank you so very much for your contributions. I've signed off on the PR, it looks good to me.

Thank you everyone for the review and the merge!

FYI, this change should be available on vcpkg at some time next week with the October release of the Azure SDK.

To hopefully clarify, we are planning to release this change as 1.11.0-beta.1 on Thursday, October 5th.
Please note, since this goes to a beta release, and the beta release is for the library already had stable releases, the further Betas do not go to the official vcpkg repo. Usually, the beta changes are baked for a month until they are released in stable release. If you are looking for this change to appear in the vcpkg official repo, you'll probably need to wait until, I'd say, November 10th.
Otherwise, this change will be available in our Beta vcpkg registry - https://github.com/Azure/azure-sdk-vcpkg-betas - it should happen on October 5th.

Hi I have noticed that azure-core_1.11.0, which has my patch, doesn't get released on 10th Nov.
Would you kindly advise when will it be done? Thank you!

Hi @ahsonkhan @antkmsft @LarryOsterman would you please kindly advise when will this patch be released?

We are hoping to release it in a GA release today, January 11, 2024.

authors: LarryOsterman antkmsft phoebusm


text:
[AutoPR compute/resource-manager] Moving Priority and EvictionPolicy enum to the definitions section and adding 'Spot' priority. Updating both 2019-03-01 and 2019-07-01 Api versions.

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

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/6312

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/6312

repo: Azure/azure-sdk-for-go


text:
[BUG] CosmosAsyncClient client returns 404 even if document exists

Describe the bug
Hi,
I have one collection that usually consumes lots of read RUs.
When I am reading from that collection I intermittently get 404 from read call. I have confirmed that document does exists before I make this read call.
I am using CosmosAsyncClient from azure-cosmos 4.7.0
Following is the trace of exception:
com.azure.cosmos.implementation.NotFoundException: ["Resource Not Found. Learn more: https://aka.ms/cosmosdb-tsg-not-found"] at com.azure.cosmos.implementation.directconnectivity.rntbd.RntbdRequestManager.messageReceived(RntbdRequestManager.java:812) [azure-cosmos-4.7.0.jar!/:?] at com.azure.cosmos.implementation.directconnectivity.rntbd.RntbdRequestManager.channelRead(RntbdRequestManager.java:181) [azure-cosmos-4.7.0.jar!/:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324) [netty-codec-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296) [netty-codec-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) [netty-handler-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1533) [netty-handler-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282) [netty-handler-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329) [netty-handler-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) [netty-codec-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) [netty-codec-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) [netty-codec-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) [netty-transport-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.59.Final.jar!/:4.1.59.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.59.Final.jar!/:4.1.59.Final] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291]
Can someone confirm if this behaviour is due to high RU consumption by other processes or some thing else entirely ?
If it is former then shouldn't the returned value be 429 instead of 404 ?
To Reproduce
Issue is intermittent
Code Snippet
Add the code snippet that causes the issue.
Expected behavior
Document should be returned if reads are done after writes with bounded staleness consistency.
Screenshots
If applicable, add screenshots to help explain your problem.
Setup (please complete the following information):

OS: Linux
IDE: [e.g. IntelliJ]
Library/Libraries: azure-cosmos:4.7.0
Java version: 8
App Server/Environment: Tomcat
Frameworks: Spring Boot

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

Hi @rishabhgpt, thank you for filing this github issue.  Someone from the Cosmos sdk team will follow up with you shortly.
/cc @kushagraThapar

@rishabhgpt What consistency your are using on your account ? In lower consistency parallels write might not reflect in parallel read immediately , please refer https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
Also are you using same client to read and write ?
Can you please provide the request diagnostics string in cosmos exception  https://github.com/Azure/azure-sdk-for-java/blob/f81a4df53929b6b60caf66fabd9c3b1d726add8e/sdk/cosmos/azure-cosmos/src/main/java/com/azure/cosmos/CosmosException.java#L292

We are using Bounded staleness
On Wed, 15 Sep 2021 at 6:54 PM, Naveen Singh @.***>
wrote:

@rishabhgpt https://github.com/rishabhgpt What consistency your are
using on your account ? In lower consistency parallels write might not
reflect in parallel read immediately , please refer
https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
Also are you using same client to read and write ?
Can you please provide the request diagnostics string in cosmos exception
https://github.com/Azure/azure-sdk-for-java/blob/f81a4df53929b6b60caf66fabd9c3b1d726add8e/sdk/cosmos/azure-cosmos/src/main/java/com/azure/cosmos/CosmosException.java#L292
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-sdk-for-java/issues/23901#issuecomment-920016178,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZQ5L3P3VHHKESXI32CHLTUCCNCXANCNFSM5DLCI6OQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Sent from Gmail Mobile

Please provide full diagnostics as mentioned above

authors: joshfree rishabhgpt simplynaveen20

repo: Azure/azure-sdk-for-java


text:
[BUG][azure-spring-boot-starter-servicebus-jms][qpid] Message is put to DLQ after MaxDeliveryCountExceeded even when message is processed without error/exception

This issue is related to azure support tickets
TrackingID#2109220050000347 and Ticket-number #11091792 detailed logs are attached in first ticket.
Describe the bug
We are consuming messages from servicebus (SB). While we don't see the spikes in SB everything works well. However when there's spike (a lot of incoming messages  msgcount > 10k) messages are being retried and then put to DLQ with reason MaxDeliveryCountExceeded.
It seems like message commit is not processed correctly in servicebus and/or the commit is not delivered to SB and we don't see any error in client library.
Exception or Stack Trace
no stacktrace, no exception
To Reproduce
Steps to reproduce the behavior: that's a question to you, but probably put > 10k messages to SB and try to process them.
Code Snippet
Here in archivingUsageTrackingService we are sending message to another topic.
  @JmsListener(destination = "${azure.servicebus.queues.usageActivity}", containerFactory = JMS_FACTORY_NAME)
  public void consume(UsageMessage usageMessage) {
    log.info("UsageMessage received: {}", usageMessage);
    usageTrackingService.processUsageMessage(usageMessage);
    archivingUsageTrackingService.trackErsUsage(usageMessage);
  }

Following is the config for queue/topic factories
  @Bean
  public JmsListenerContainerFactory<?> fiscalJmsFactory(ConnectionFactory connectionFactory,
      DefaultJmsListenerContainerFactoryConfigurer configurer) {
    if (connectionFactory instanceof CachingConnectionFactory) {
      CachingConnectionFactory cachingConnectionFactory = (CachingConnectionFactory) connectionFactory;
      cachingConnectionFactory.setCacheProducers(false);
    }
    DefaultJmsListenerContainerFactory factory = new DfDefaultJmsListenerContainerFactory();
    factory.setErrorHandler(t -> log.error("Unable to process JMS message", t));
    factory.setExceptionListener(t -> log.error("Unable to process JMS message", t));
    factory.setMessageConverter(jacksonJmsMessageConverter());
    configurer.configure(factory, connectionFactory);
    return factory;
  }

  @Bean
  @ConditionalOnProperty(prefix = "df.azure.servicebus", name = "enableJmsTopic", havingValue = "true")
  public JmsListenerContainerFactory<?> fiscalJmsTopicFactory(ConnectionFactory connectionFactory,
      DefaultJmsListenerContainerFactoryConfigurer configurer) {
    if (connectionFactory instanceof CachingConnectionFactory) {
      CachingConnectionFactory cachingConnectionFactory = (CachingConnectionFactory) connectionFactory;
      cachingConnectionFactory.setCacheProducers(false);
    }
    DefaultJmsListenerContainerFactory factory = new DfDefaultJmsListenerContainerFactory();
    factory.setErrorHandler(t -> log.error("Unable to process JMS message", t));
    factory.setExceptionListener(t -> log.error("Unable to process JMS message", t));
    factory.setMessageConverter(jacksonJmsMessageConverter());
    factory.setSubscriptionDurable(true);
    configurer.configure(factory, connectionFactory);
    return factory;
  }

and this  is our customized JmsListenerContainerFactory
@Getter
@Setter
public class DfDefaultJmsListenerContainerFactory extends DefaultJmsListenerContainerFactory {

  private Boolean exposeListenerSession = Boolean.FALSE;

  @Override
  protected void initializeContainer(DefaultMessageListenerContainer container) {
    super.initializeContainer(container);
    if (this.exposeListenerSession != null) {
      container.setExposeListenerSession(this.exposeListenerSession);
    }
  }

}

Expected behavior
Whenever message is processed without any error it should be removed from SB queue and not moved to DLQ. OR when message couldn't be removed from queue because of any reason, we should see some error in client library.
Screenshots
Spike:
here we can see some client errors, but no error/exception is reported by underlying library.

Setup (please complete the following information):

OS: kubernetes
Library/Libraries: azure-spring-boot-starter-servicebus-jms 3.7.0
Java version: 11
App Server/Environment: tomcat 9.0.52
Frameworks: spring-boot 2.5.4

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

And here you can see that there is some correlation between number of incoming messages and client errors. But our microservice always processes only one message concurrently and we have maximal 7 instances of this microservice. So we concurrently process only 7 messages. Our application does not have any high usage of resources during these peeks.  When we resend these messages into the same queue then these messages are normally processed on the first attempt. And as you can see there is almost no user error only during these peeks. And our application is "pretty" fast because it is able to process all messages 10 times during 10min but it is not able to acknowledge them.

Hi @Saljack and @bilak , thanks for your reporting. This is due to the default prefetch count of 1000 is used, and with your configuration of max-delivery-count and lock-duratition, the prefetched messages cannot be consumed before the configuration expire, so they are dead lettered. We will fix this soon by providing a configuration option of prefetch.

@yiliuTo Can you give us more details? Because I do not understand what you mean by prefetch. If I understand correctly the issue is in your library am I right? Is there the issue in qpid-proton-j or qpid-jms or  spring-jms or an Service Bus library or directly in Service Bus? Is there any workaround because we have to resend everyday thousands of messages so it is not ok for us. Increasing number of max delivery count does not help only restarting our application helped to process some messages I have already tested it on our testing environment.

Can you provide any date/milestone/plan when when it should be fixed? Why isn't there any error in logs?

@yiliuTo Yes we use standard tier. I will test it we do not need to wait for your fix because we use our modified connection factory anyway. You can implement it as an general customizer which customize JmsConnectionFactory in the factory bean merhod. The strange thing is that it starts if there is more than 10 000 messages and then all communication with the queue in Azure Service Bus is completely dead locked until moving some messages to DLQ. You can see it in my graph that when it reached this limit then it was not able to acknowledge any message for 6hours (there was set max delivery count to 500). I still do not understand why if there is less than 10k messages this issue is not there and I can see it even if I have 7 or 3 client applications. It looks like there is some limitation directly in Azure Services Bus. Does premium tier use completely different library or API (I know it supports JMS 2.0).

@Saljack for premium tier we rely on another library of com.microsoft.azure:azure-servicebus-jms:0.0.7 for the connection factory, which sets the default value of prefetch as 0.
For the phenomanon in your case, could you share your configuration of the lock duration? And how long does it take for your client to consume one message? Also in the picture you provided, how many client applications were there in 6pm and when you adjusted the max dilivery count?

@yiliuTo  There were 2-3 instances so I would say 3 because it scales fast. Lock duration is 1 min. And one message is processed in a few milliseconds (I checked randomly a few messages and it is +-4ms). In the second repetition it would be faster. So if I count correct then 10ms (per message) x 1000 messages = 10s so it should be ok and there is huge space to 1 min. I increased max delivery count at +- 6:50pm (I have already marked it in my graph). You can se that from +-7pm when it reached a limit then no message was acknowledged until 3am. But if you set prefetch to 0 then it would be pretty slow. I had to already disable producer caching so it is next slow down regarding Azure Services Bus.

@Saljack One of the possible reasons for the dead-locking is that, there is one message being consumed over the lock duration(1min), then it causes consuming-time * max-delivery-count of dead locking , because your client rotates in fetching it from SB and then consuming for 500 times. You could check if that's the reason by checking the longest consuming time of all messages and see if there are ones over your lock-duration. If so, perhaps you could consider add custom consuming logic for those messages instead of dealing with them directly. And just increasing max-diliverty-count might not be a good solution for it might expand some small issues.

@yiliuTo No it is impossible because I sent completely the same message (i change only created date) for testing 20 000 times and therefore the logic do the same thing all the time.

@yiliuTo Change prefetch policy to 0 works like a charm in my tests 👍. Can you set it as default value?

@yiliuTo Could you ping me internally, thanks

@yiliuTo There were 2-3 instances so I would say 3 because it scales fast. Lock duration is 1 min. And one message is processed in a few milliseconds (I checked randomly a few messages and it is +-4ms). In the second repetition it would be faster. So if I count correct then 10ms (per message) x 1000 messages = 10s so it should be ok and there is huge space to 1 min. I increased max delivery count at +- 6:50pm (I have already marked it in my graph). You can se that from +-7pm when it reached a limit then no message was acknowledged until 3am. But if you set prefetch to 0 then it would be pretty slow. I had to already disable producer caching so it is next slow down regarding Azure Services Bus.

Hi @Saljack and @bilak, can you use command ulimit -a to see the number of file descriptors in the machine? I think it may because of the limit of the number of file descriptors, if so you can increase the number.
Also, I will change the code to set the default prefetch count as 0, and if time is enought I will also expose a parameter to set the prefetch count, and then I will release the library this month.

@Saljack we have release  azure-spring-boot-starter-servicebus-jms3.10.0, the parameter list is here.

authors: Saljack backwind1233 bilak malsdorf yiliuTo


text:
Move GeoJSON Types from Azure Core to Azure Core Experimental

This PR moves the GeoJSON types from Azure Core to Azure Core Experimental. In addition to moving these classes Azure Search is updating/removing its use of the GeoJSON types.

/azp run java - search - tests

/azp run java - search - tests


text:
Sync eng/common directory with azure-sdk-tools for PR 1517

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/1517  See eng/common workflow

/check-enforcer override

authors: azure-sdk chidozieononiwu


text:
Fix connection leak in rest proxy when return type is void or mono

Caught in perf pipelines.
Rest Proxy would leak connections if interface method returns void or Mono like this
https://github.com/Azure/azure-sdk-for-java/blob/cf1b7dc7dd6a5b843e06b6361fd7826be23fe26a/sdk/core/azure-core-perf/src/main/java/com/azure/core/perf/core/MyRestProxyService.java#L39-L43
The symptoms were perf of OkHttp client grossly underperforming in core perf pipeline. Attempt to reproduce revealed OkHttp complaining about undisposed responses.

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

Test
Arguments
1.30.0
source
%Change

jsonsend
--size 10 --parallel 64 --backend-type blobs --warmup 15 --duration 15
10809.14
13017.89
20.43%

jsonsend
--size 1000 --parallel 64 --backend-type blobs --warmup 15 --duration 15
13067.39
12907.40
-1.22%

jsonreceive
--size 10 --parallel 64 --backend-type blobs --warmup 15 --duration 15
25888.90
25900.12
0.04%

jsonreceive
--size 1000 --parallel 64 --backend-type blobs --warmup 15 --duration 15
24803.62
24613.67
-0.77%

xmlsend
--size 10 --parallel 64 --backend-type blobs --warmup 15 --duration 15
12979.08
13008.76
0.23%

xmlsend
--size 1000 --parallel 64 --backend-type blobs --warmup 15 --duration 15
12987.90
12897.35
-0.70%

xmlreceive
--size 10 --parallel 64 --backend-type blobs --warmup 15 --duration 15
25610.82
25652.50
0.16%

xmlreceive
--size 1000 --parallel 64 --backend-type blobs --warmup 15 --duration 15
22679.80
22560.85
-0.52%

binarydatasend
--size 10240 --binary-data-source bytes --parallel 16 --backend-type blobs --warmup 15 --duration 15
3511.92
3483.51
-0.81%

binarydatasend
--size 10240 --binary-data-source file --parallel 16 --backend-type blobs --warmup 15 --duration 15
3475.10
3467.56
-0.22%

binarydatasend
--size 10240 --binary-data-source flux --parallel 16 --backend-type blobs --warmup 15 --duration 15
3535.32
3491.02
-1.25%

binarydatasend
--size 10240 --binary-data-source stream --parallel 16 --backend-type blobs --warmup 15 --duration 15
3459.40
3457.61
-0.05%

binarydatasend
--size 10485760 --binary-data-source bytes --parallel 8 --backend-type blobs --warmup 15 --duration 15
81.08
80.11
-1.20%

binarydatasend
--size 10485760 --binary-data-source file --parallel 8 --backend-type blobs --warmup 15 --duration 15
105.30
104.76
-0.51%

binarydatasend
--size 10485760 --binary-data-source flux --parallel 8 --backend-type blobs --warmup 15 --duration 15
85.41
84.63
-0.91%

binarydatasend
--size 10485760 --binary-data-source stream --parallel 8 --backend-type blobs --warmup 15 --duration 15
107.54
107.99
0.42%

binarydatasend
--size 10240 --binary-data-source bytes --parallel 16 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
323.99
3497.93
979.63%

binarydatasend
--size 10240 --binary-data-source file --parallel 16 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
317.47
3476.57
995.09%

binarydatasend
--size 10240 --binary-data-source flux --parallel 16 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
317.97
3457.69
987.43%

binarydatasend
--size 10240 --binary-data-source stream --parallel 16 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
320.68
3484.87
986.70%

binarydatasend
--size 10485760 --binary-data-source bytes --parallel 8 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
37.11
65.96
77.74%

binarydatasend
--size 10485760 --binary-data-source file --parallel 8 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
40.04
64.60
61.34%

binarydatasend
--size 10485760 --binary-data-source flux --parallel 8 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
39.07
65.14
66.75%

binarydatasend
--size 10485760 --binary-data-source stream --parallel 8 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
39.14
69.91
78.64%

binarydatareceive
--size 10240 --parallel 16 --backend-type blobs --warmup 15 --duration 15
6637.52
6596.31
-0.62%

binarydatareceive
--size 10485760 --parallel 8 --backend-type blobs --warmup 15 --duration 15
105.87
107.03
1.10%

binarydatareceive
--size 10240 --parallel 16 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
6462.88
6479.88
0.26%

binarydatareceive
--size 10485760 --parallel 8 --backend-type blobs --http-client okhttp --warmup 15 --duration 15
39.48
38.94
-1.35%

authors: azure-sdk kasobol-msft


text:
Servicebus Java SDK November 2022 release

Description
Servicebus Java SDK November 2022 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.

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:
Increment versions for communication releases

Increment package versions for communication releases

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


text:
Added check to ensure a secret name is not null or empty when using the getSecret operations

Fixes: #32460.
We recently noticed that passing both an empty secret name and version for the getSecret() or getSecretWithResponse() operations could cause an HttpResponseException to be thrown by our clients with an unexpected message saying "Deserialization Failed". While we had documented the type of exception to be thrown if either parameter was empty, the fact that it shows the problem happened at the deserialization stage shows the problem happened on our end because the HTTP pipeline could not handle the response given by the server, as it thought we were calling the {keyvault-url}/secrets/ endpoint (used for listing secrets) instead of {keyvault-url}/secrets/{secret-name}/{secret-version}. Moreover, the server allows for just passing a secret name with no version if a user wishes to retrieve the latest version of said secret.
I think the fact that we throw an HttpResponseException when the server did not give us any error can be misleading and it's worth considering either adding a check and changing the exception type to something more appropriate, or at least providing a better error message (even if we keep the exception type unchanged, which feels bad in my opinion).
Any thoughts on this @srnagar, @lmolkova, @JonathanGiles?

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


text:
Add Wildcard Support for Header Logging

Fixes #6031
This PR adds the ability for the HttpLogOptions class to have patterns which are used to match headers during logging. This is done through an additional set of options to add pattern strings which will be used and concatenated to create a single Pattern which matches case-insensitively against the headers sent and returned during request and response.
Additional minor changes were performed the the HttpLoggingPolicy to clone the values of the passed HttpLogOptions instead of accessing them during log time to reduce duplicative work that only needs to be performed during construction of the policy.

Closing PR as implementation needs additional discussion.