text:
Can you use standard Virtual Machine ARM Template options?

When I create a new SQL IAAS VM, I am able to choose all sorts of SQL options, such as enabling SQL Authentication.  I want to use these in my DevTest VMs too.
I have looked at the ARM templates produced by the standard Virtual Machines blade.  Is this transferable into the DevTest VM ARM template?

Not yet. We are working on a feature to deploy ARM templates to a lab instead of creating a VM directly. With that you can specify additional parameters to Compute to configure SQL, etc.

source: gharchive/issue

authors: drwill-ms gregpakes

repo: Azure/azure-devtestlab

license: mit

license_type: permissive

license_source: bigquery


text:
Docker Extension doesn't work

Since today,
I'm experiencing following issue when Docker Extension is used:
[ERROR] New-AzureRmResourceGroupDeployment : 3:13:27 PM - VM has reported a failure
[ERROR] when processing extension 'DockerExtension'. Error message: "Enable Docker
[ERROR] failed: ERROR: executing /bin/sh [-c curl -sSL https://get.docker.com/ | sh]
[ERROR] failed: exit status 1".
May be there are some issue while trying to download Docker bits ?
Thanks

It seems this issue is related to CenOs 7.2.
No issues with Ubuntu 16.04

After some diggings, it seems CentOs has updated a package and OpenLogic repository is still point to the old one.

Issue still available

Can you check again, this should be resolved now.

Confirmed. Docker extension on CentOs now work again.
Packages have been updated

authors: giovannifl szarkos

repo: Azure/azure-docker-extension


text:
Docs.MS CI Updates for Azure.Template

CI Update for release of Azure.Template

Docs Build status updates of commit 22903b4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

bundlepackages/azure-dotnet-preview.csv
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

source: gharchive/pull-request

authors: VSC-Service-Account azure-sdk

repo: Azure/azure-docs-sdk-dotnet

license_source: github-api


text:
Azure Function within Docker container - No job functions found

Hoping someone can help me! Appreciate this is close to the following issue previous raised: https://github.com/Azure/azure-functions-docker/issues/128
Unfortunately the above link didnt solve my problem.
I added docker to an existing azure function that I had previously built. This was done via the docker support functionality within visual studio. The created dockerfile runs perfectly fine within visual studio. Having looked at what commands VS runs these are significantly different to what I am expecting to run. One to build the docker image and two to spin up the container.
Dockerfile:
FROM mcr.microsoft.com/azure-functions/dotnet:3.0 AS base
WORKDIR /home/site/wwwroot
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:3.1 AS build
WORKDIR /src
COPY ["NuGet.config", "."]
COPY ["XXXX/XXXX.csproj", "XXXX/"]
RUN dotnet restore "XXXX/XXXX.csproj"
COPY . .
WORKDIR "/src/XXXX"
RUN dotnet build "XXXX.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "XXXX.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /home/site/wwwroot
COPY --from=publish /app/publish .
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

Therefore I am looking to one run the following Build command:
docker build -f Dockerfile . -t newtest
This on face value looks like it has succeeded.
Here is the output of the above:
[+] Building 68.8s (19/19) FINISHED
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 906B                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for mcr.microsoft.com/dotnet/sdk:3.1                                                                                0.2s
 => [internal] load metadata for mcr.microsoft.com/azure-functions/dotnet:3.0                                                                          0.2s
 => [base 1/2] FROM mcr.microsoft.com/azure-functions/dotnet:3.0@sha256:3ce9888785b6ad4a4a219e2c5beaf32add1ec6a2c8514f88a596bbcaa58f1312               0.0s
 => [internal] load build context                                                                                0.1s
 => => transferring context: 166.44kB                                                                                0.0s
 => [build 1/8] FROM mcr.microsoft.com/dotnet/sdk:3.1@sha256:2db1d2c81c51ce4a5b0ed41d439839ee3a1c90b415c3e03ca987478cef7a1371                         22.9s
 => => resolve mcr.microsoft.com/dotnet/sdk:3.1@sha256:2db1d2c81c51ce4a5b0ed41d439839ee3a1c90b415c3e03ca987478cef7a1371                                0.0s
 => => sha256:61441cac53211e0132831cf4977286fce5b9d8c50d1df80763b148211c4dda2e 6.43kB / 6.43kB                                                         0.0s
 => => sha256:ba3959e1529771ae9fb5393fc19cd8b236814c45043e81fb64f1c7a0ca8066a8 13.70MB / 13.70MB                                                       2.5s
 => => sha256:449df86cd0f646dbe9e8eb3b22b5ca3f19827797edc58bc8c8d34493194676cf 13.23MB / 13.23MB                                                       2.5s
 => => sha256:c6d947c32e6215ba4f98050e9f7b7925fb9c72c244fca5b2e40eb4d5ac51aeaa 1.80kB / 1.80kB                                                         0.0s
 => => sha256:2641eac4b740ed8558510f7dfd06fa8c52c0c0a64934d5cc0faeb00e420538f6 124.17MB / 124.17MB                                                     8.3s
 => => sha256:2db1d2c81c51ce4a5b0ed41d439839ee3a1c90b415c3e03ca987478cef7a1371 2.17kB / 2.17kB                                                         0.0s
 => => extracting sha256:ba3959e1529771ae9fb5393fc19cd8b236814c45043e81fb64f1c7a0ca8066a8                                                              0.7s
 => => extracting sha256:2641eac4b740ed8558510f7dfd06fa8c52c0c0a64934d5cc0faeb00e420538f6                                                             12.6s
 => => extracting sha256:449df86cd0f646dbe9e8eb3b22b5ca3f19827797edc58bc8c8d34493194676cf                                                              0.9s
 => [build 2/8] WORKDIR /src                                                                                0.8s
 => [build 3/8] COPY [NuGet.config, .]                                                                                0.1s
 => [build 4/8] COPY [XXXX.csproj, XXXX/]                                          0.1s
 => [build 5/8] RUN dotnet restore "XXXX/XXXX.csproj"                             27.8s
 => [build 6/8] COPY . .                                                                                0.4s
 => [build 7/8] WORKDIR /src/XXXX                                                                                0.0s
 => [build 8/8] RUN dotnet build "XXXX.csproj" -c Release -o /app/build                                              8.9s
 => [publish 1/1] RUN dotnet publish "XXXX.csproj" -c Release -o /app/publish                                        6.9s
 => CACHED [base 2/2] WORKDIR /home/site/wwwroot                                                                                0.0s
 => CACHED [final 1/2] WORKDIR /home/site/wwwroot                                                                                0.0s
 => [final 2/2] COPY --from=publish /app/publish .                                                                                0.1s
 => exporting to image                                                                                0.3s
 => => exporting layers                                                                                0.2s
 => => writing image sha256:a30d6d99db2ced202d31789daabd319174659b2337b42a2963b74ca3b9082757                                                           0.0s
 => => naming to docker.io/library/newtest

After the build succeeds the next command I am running is:
Command
docker run -it --rm -p "5500:80" newtest
Output
warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Overriding address(es) 'http://+:80'. Binding to endpoints defined in UseKestrel() instead.
info: Host.Triggers.Warmup[0]
      Initializing Warmup Extension.
info: Host.Startup[503]
      Initializing Host. OperationId: '2984e8f7-610d-4934-93d9-4c506cf9f56d'.
info: Host.Startup[504]
      Host initialization: ConsecutiveErrors=0, StartupCount=1, OperationId=2984e8f7-610d-4934-93d9-4c506cf9f56d
info: Microsoft.Azure.WebJobs.Hosting.OptionsLoggingService[0]
      LoggerFilterOptions
      {
        "MinLevel": "None",
        "Rules": [
          {
            "ProviderName": null,
            "CategoryName": null,
            "LogLevel": null,
            "Filter": "<AddFilter>b__0"
          },
          {
            "ProviderName": "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.SystemLoggerProvider",
            "CategoryName": null,
            "LogLevel": "None",
            "Filter": null
          },
          {
            "ProviderName": "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.SystemLoggerProvider",
            "CategoryName": null,
            "LogLevel": null,
            "Filter": "<AddFilter>b__0"
          }
        ]
      }
info: Microsoft.Azure.WebJobs.Hosting.OptionsLoggingService[0]
      ConcurrencyOptions
      {
        "DynamicConcurrencyEnabled": false,
        "MaximumFunctionConcurrency": 500,
        "CPUThreshold": 0.8,
        "SnapshotPersistenceEnabled": true
      }
info: Microsoft.Azure.WebJobs.Hosting.OptionsLoggingService[0]
      FunctionResultAggregatorOptions
      {
        "BatchSize": 1000,
        "FlushTimeout": "00:00:30",
        "IsEnabled": true
      }
info: Microsoft.Azure.WebJobs.Hosting.OptionsLoggingService[0]
      SingletonOptions
      {
        "LockPeriod": "00:00:15",
        "ListenerLockPeriod": "00:01:00",
        "LockAcquisitionTimeout": "10675199.02:48:05.4775807",
        "LockAcquisitionPollingInterval": "00:00:05",
        "ListenerLockRecoveryPollingInterval": "00:01:00"
      }
info: Microsoft.Azure.WebJobs.Hosting.JobHostService[0]
      Starting JobHost
info: Host.Startup[401]
      Starting Host (HostId=02519606f196-2137340777, InstanceId=f51daae3-b514-4d9a-8516-fb8c1e9c30da, Version=3.4.2.0, ProcessId=1, AppDomainId=1, InDebugMode=False, InDiagnosticMode=False, FunctionsExtensionVersion=(null))
info: Host.Startup[314]
      Loading functions metadata
info: Host.Startup[315]
      0 functions loaded
info: Host.Startup[0]
      Generating 0 job function(s)
warn: Host.Startup[0]
      No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
info: Microsoft.Azure.WebJobs.Hosting.OptionsLoggingService[0]
      HttpOptions
      {
        "DynamicThrottlesEnabled": false,
        "EnableChunkedRequestBinding": false,
        "MaxConcurrentRequests": -1,
        "MaxOutstandingRequests": -1,
        "RoutePrefix": "api"
      }
info: Microsoft.Azure.WebJobs.Script.WebHost.WebScriptHostHttpRoutesManager[0]
      Initializing function HTTP routes
      No HTTP routes mapped

info: Host.Startup[412]
      Host initialized (39ms)
info: Host.Startup[413]
      Host started (49ms)
info: Host.Startup[0]
      Job host started
Hosting environment: Production
Content root path: /azure-functions-host
Now listening on: http://[::]:80
Application started. Press Ctrl+C to shut down.
info: Host.General[337]
      Host lock lease acquired by instance ID '00000000000000000000000086D15900'.
^CApplication is shutting down...
info: Microsoft.Azure.WebJobs.Hosting.JobHostService[0]
      Stopping JobHost
info: Host.Startup[0]

As you can see the output above shows:
info: Host.Startup[315]
0 functions loaded
info: Host.Startup[0]
Generating 0 job function(s)
warn: Host.Startup[0]
No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
I cant for the life of me figure out why no job functions are being found, considering running it via VS produces in successful build & run. I even tested via consuming the expected endpoints successfully.
Apologies if I havent produced every log available, im a newbie when it comes to docker and containerisation, hence trying to get it working with an existing application

Experiencing the same issue here ...  Deploying a container to a private container registry on Azure. The app service hosting the functions is connected to the deployed container via the linuxFxVersion setting on the app service. The docker logs via Kudu show that the container is pulled successfully. No functions shown in the portal after this, and a call to the HttpTrigger enabled function returns a 404.
Clearly this implies that the runtime is not picking up the functions. Does this have to do anything with the version of the functions runtime? I don't think so, because when I pull the deployed to my local machine, and call the HttpTrigger endpoint, then it runs just fine.

I found the culprit to be the persistent shared storage. If you are using WEBSITES_ENABLE_APP_SERVICE_STORAGE set to true, this will mount over the /home directory of the container prior to execution. This effectively hides the app and files from the container runtime.
https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?pivots=container-linux#use-persistent-shared-storage

Additionally, any contents inside the /home directory of the container are overwritten by any existing files already present on the persistent storage when the container starts.

There appears to be no easy way to change this in Azure. The startup code specifically finds if the container is running in Azure (identifies if there is the environment variable WEBSITE_INSTANCE_ID), and then sets the path to /home/site/wwwroot assuming that the environment variable HOME is unset or set to /home. Despite the property being called IsAppServiceEnvironment, it's referring to Azure App Services as a whole and not just App Service Environment hosted applications.
https://github.com/Azure/azure-functions-host/blob/2c95cfe1354c3743f387cadcd03f4144dffe184d/src/WebJobs.Script/Description/DotNet/FunctionAssemblyLoadContext.cs#L590-L600
The environment variable AzureWebJobsScriptRoot is ignored in Azure App Services.

@nerddtvg @sergevm @CAJTechnologyLimited  I'm facing the same issue with custom docker image on node platform. Did any of you find a fix or workaround for this?

I'm facing the same issue with custom docker image on node platform. Did any of you find a fix or workaround for this?

@prabhurajshell The only solution I have is from my comment above to not use WEBSITES_ENABLE_APP_SERVICE_STORAGE.

@nerddtvg  Thank you, setting WEBSITES_ENABLE_APP_SERVICE_STORAGE as false worked for me. Are there any downsides to performance if we are not using the persistent storage?

We were having a problem with the exact same symptoms but the fix turned out to be different than the WEBSITES_ENABLE_APP_SERVICE_STORAGE.  We were upgrading an existing functions 3 to run on the 4 framework and everything was working fine running the container locally but refused to recognize any functions in azure.  Turns out the issue was the path we were using in the docker build command.
Previously the devops pipeline would run the equivalent of this command, within the project directory:
docker build -f Dockerfile . and the build step within the dockerfile looked like:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["myproject.csproj", "myproject/"]
RUN dotnet restore "myproject/myproject.csproj"
COPY . .
WORKDIR "/src/myproject"
RUN dotnet build "myproject.csproj" -c Release -o /app/build

The trick turns out to be running the build from one directory up at the solution level... Command updated to:
docker build -f myproject/Dockerfile .
and build step changed to:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["myproject/myproject.csproj", "myproject/"]
RUN dotnet restore "myproject/myproject.csproj"
COPY . .
WORKDIR "/src/myproject"
RUN dotnet build "myproject.csproj" -c Release -o /app/build

Not sure why it was different between v3 and v4, or why it worked locally, but there it is.

Our team also ran into this issue. We resolved it by setting WEBSITES_ENABLE_APP_SERVICE_STORAGE to false.
This triggered a different issue related to the permissions for the following directory /home/LogFiles/Application/Functions/Host.
If you run into this verify that this directory exists inside your container and that the access level for /home and subfolders is open to non-root users

Upgrading the function runtime worked for me, Dockerfile:
FROM mcr.microsoft.com/azure-functions/node:4-nightly-node18
ENV AzureWebJobsScriptRoot=/home/site/wwwroot
AzureFunctionsJobHost__Logging__Console__IsEnabled=true
COPY . /home/site/wwwroot
RUN cd /home/site/wwwroot &&
npm install &&
npm run build

authors: CAJTechnologyLimited Christopher-Flanagan axl8652 nerddtvg prabhurajshell sergevm svickers

repo: Azure/azure-functions-docker

license: MIT


text:
Model casing is changed

I defined an XML request like the following :
        [OpenApiRequestBody(contentType: "text/xml", bodyType: typeof(Model.MyClass))]
public class MyClass
{
    public MySubClass MySubClass { get; set; }
}

public class MySubClass
{
    public string MyProperty { get; set; }
}

Then when I look in the generated UI, the casing I have defined has changed:
<?xml version="1.0" encoding="UTF-8"?>
<myClass>
	<mySubClass>
		<myProperty>string</myProperty>
	</mySubClass>
</myClass>
So far, the only solution I have found is to redefine the name of each property using the JsonProperty decorator.
For instance:         [JsonProperty("MyProperty")]
Also does it make sense to use that decorator when my request is 'text/xml' ?
It looks like this extension is made for JSON and XML is an afterthought.

At the moment it doesn't look like there is a way to override this using the main package that provides the templates, but if you copy in the three OpenAPI template files (OpenApiConfiguration, OpenApiHttpTrigger, and OpenApiHttpTriggerContext) and reference the Microsoft.Azure.WebJobs.Extensions.OpenApi.Core package instead, you can then change NamingStrategy on OpenApiHttpTriggerContext to be new DefaultNamingStrategy() instead of using CamelCaseNamingStrategy

@gsimardnet Thanks for the issue! You can use the suggestion by @ssa3512 as a workaround. In the meantime, I'll have a look at the configuration that can be overrideable, which is on:
https://github.com/Azure/azure-functions-openapi-extension/blob/7f70286964d0abc3fc88be32da11f50cce6652ba/src/Microsoft.Azure.WebJobs.Extensions.OpenApi.Core/IOpenApiConfigurationOptions.cs#L10-L21

@justinyoo if you want to assign this to me I should be able to get a PR up later this week or weekend.

@ssa3512 Thanks for your support!

This is still an issue, or atleast also an issue in .NET isolated using 'Microsoft.Azure.Functions.Worker.Extensions.OpenApi'.
'UseNewtonsoftJson' uses the 'CamelCasePropertyNamesContractResolver', see:
https://github.com/Azure/azure-functions-openapi-extension/blob/ab184cbf3c8ff16378cfa00fa1cb23cb58ac1727/src/Microsoft.Azure.Functions.Worker.Extensions.OpenApi/Extensions/FunctionsWorkerApplicationBuilderExtensions.cs#L37
This seems like a strange choice as default, as it differs from default serializer (System.Text.Json) in a new isolated Function App.
For anyone looking to disable this, you can do the following:
worker.UseNewtonsoftJson(new JsonSerializerSettings
{
    ContractResolver = new DefaultContractResolver()
});

Is there a reason camel case is defaulted?

Implemented and opened as PR #646.
I agree that camel case as default is possibly not the optimal choice (personally not my desired one anyway), but changing that would obviously be a breaking change.

authors: Ausxor CSymes gsimardnet justinyoo ssa3512

repo: Azure/azure-functions-openapi-extension


text:
Doesn't support Azure sovereign cloud

When ingesting logs to kusto in usgovvirginia region, I got the following error.
ingest.New client failed with error: problem reading ingestion resources from Kusto: the StorageRoot URI received(https://***.blob.core.usgovcloudapi.net/2022*******0Z&sp=rw) has an error: URI hostname does not end with '.core.windows.net'
Could we add interface for adding trusted endpoints? Just like in this doc:  https://docs.microsoft.com/en-us/azure/data-explorer/kusto/api/connection-strings/kusto#trusted-endpoints

You are right, this validation is not cloud agnostic.
labeled as bug for fixing

Fixed in 0.10.1

authors: AsafMah yogilad zetiaatgithub

repo: Azure/azure-kusto-go


text:
Added alignment of headers according to spec

Added headers to kscb, tests, etc

@yogilad I refactored it to remove the logic out of KSCB, take another look.


text:
Apple device token (64 characters) is not accepted by ANH

I tried, using this sdk, to register, for example, the following devicetoken (optained via device):
96d6bb5d 412881d3 0046f5bf 5616bead df6aa4ab e57987bc cc4b5c23 209dbb0c
I tried the following things:

as is; with spaces
remove spaces
dashes instead of spaces

But they all give next error in return:
com.windowsazure.messaging.NotificationHubsException: Error: HTTP/1.1 400 Bad Request - 400One or more characters in device token is not a hexadecimal digit..TrackingId:c9b0fa60-c8e7-4281-9f6c-efd7ed2b19a2_G18,TimeStamp:6/19/2018 11:57:33 AM
it seems to only accept 32 characters hexidecimal string (only first 32 characters works fine for the registration: 96d6bb5d412881d30046f5bf5616bead )
I added the library via Maven:
groupId: com.windowsazure
artifactId: NotificationHubs
version: 0.0.5
In com.windowsazure.messaging.NotificationHub next version is mentioned:
APIVERSION = "?api-version=2015-04"
Is this version too old?
What am I doing wrong?
Is this library outdated/depricated?
Is there an other/ better way to make this work?
thanks in advance for your response

problem seemes to be solved.
Solution now, with Apple device tokens, is to remove all spaces when registring the device in Azure:

from

APNS: 96d6bb5d 412881d3 0046f5bf 5616bead df6aa4ab e57987bc cc4b5c23 209dbb0c
to Azure: 96d6bb5d412881d30046f5bf5616beaddf6aa4abe57987bccc4b5c23209dbb0c


text:
[Hub Generated] Review request for Microsoft.RecoveryServices to add version stable/2022-10-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM API Information (Control Plane)
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
[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.

[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.

"title": "RecoveryServicesBackupClient",

There are a bunch of breaking changes reported on this PR. Please get a breakingchanges approval and ARM can review the changes afterwards. Once you have the approval please remove the "ARMChangesRequested" label from the PR to make the PR visible to the ARM reviewers

Refers to: specification/recoveryservicesbackup/resource-manager/Microsoft.RecoveryServices/stable/2022-10-01/bms.json:5 in 581cdcd. [](commit_id = 581cdcdfd8ff4292692107f97d953493f0f78148, deletion_comment = False)

"title": "RecoveryServicesBackupClient",

The first commit needs to be the previous api version and the new changes should only be added in the subsequent commits. This is explained in detail here (If using Open API which is recommended)  https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/208/OpenAPI-Hub-Adding-new-API-version or here(For manual process) :  https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/83/Manual-Process-Adding-new-API-version . Please remove the "ARMChangesRequested" label once you have fixed this issue.

Refers to: specification/recoveryservicesbackup/resource-manager/Microsoft.RecoveryServices/stable/2022-10-01/bms.json:5 in 581cdcd. [](commit_id = 581cdcdfd8ff4292692107f97d953493f0f78148, deletion_comment = False)

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

Marking as Approved-BreakingChanges as these changes were previously reviewed and approved in #19182

The file bms.json only shows the version number change in diff from base (2022-09-01-preview) version, no other changes. Were there more changes made in bms.json swagger spec file?

The file bms.json only shows the version number change in diff from base (2022-09-01-preview) version, no other changes. Were there more changes made in bms.json swagger spec file?

@visingla-ms :  all the changes were in preview and we're taking it to stable. so, no changes from latest preview

SigningOff PR, as the only change is version number, as confirmed by PR Author.

authors: cvarsh hiaga mikekistler rkmanda shesamian viananth visingla-ms

repo: Azure/azure-rest-api-specs


text:
Allow subscription parameter for the checkNameAvailability API

We already have the checkNameAvailability API but that does not take the subscription id as a parameter. We support the API both with subscription as an optional parameter. Added an operation which takes subscription id as a parameter.
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-python

Automation for azure-sdk-for-go

Automation for azure-libraries-for-java

Automation for azure-sdk-for-node


text:
Microsoft.CostManagement add support for existing 2023-07-01-preview API version with 2023-03-01 base

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.

[!NOTE]
As of January 2024 there is no PR assignee. This is expected. See https://aka.ms/azsdk/pr-arm-review.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Click here to see the details of Step 1, Breaking Changes review
If you are in purview of Step 1 of the diagram, follow the Breaking Changes review process.
IMPORTANT! This applies even if you believe your PR was mislabeled, for any reason, including tool failure.

Click here to see the details of Step 2, ARM review
See https://aka.ms/azsdk/pr-arm-review.

 Click here to see the diagram footnotes
Diagram footnotes
[1] See ARM review queue (for PR merge queues, see [2]).
[2] public repo merge queue, private repo merge queue (for ARM review queue, [1])
The ARM reviewer on-call engineer visits the merge queue twice a day, so the approximate ETA for merges is 12 - 24 hours.

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 generated using OpenAPI Hub).
[ ] 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

 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.
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 PR workflow diagram Step 2 (ARM review), 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.

/pr RequestMerge

Thank you for pushing this version to the repo! We see that it is the version currently used by the Azure portal UI (via Chrome inspector networking tab) and is the only supported api-version when making a raw request (copying via the Chrome inspector networking tab) to query our exports. All other versions return a 404 or an empty array.
Further, the az CLI is using api-version of 2020-06-01. Could the az tool be updated please? This I think is configured here: https://github.com/Azure/azure-cli-extensions/blob/9f7d44440451c6a555e5f60a7011bb0529de71f4/src/costmanagement/azext_costmanagement/vendored_sdks/costmanagement/_metadata.json#L2-L3

authors: amonshiz jesalaz-msft


text:
Abrinegar/azuredatatransfer/adding uri properties

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

/azp run

authors: abrinegarMicrosoft razvanbadea-msft


text:
Update a property name of SignalRService

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

Automation for azure-sdk-for-ruby

Can one of the admins verify this patch?

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go

authors: AutorestCI azuresdkci zackliu


text:
chore: update git ignore

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

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

/check-enforce override

/check-enforcer override

/check-enforcer override

/check-enforcer override

/check-enforcer override

repo: Azure/azure-sdk-for-go


text:
sdk/resourcemanager/edgezones/armedgezones live test

operation coverage: (5/5)

/azp run go - armedgezones - ci

replaced by https://github.com/Azure/azure-sdk-for-go/pull/23627

authors: Alancere tadelesh


text:
[AutoPR storage/resource-manager] [DO NOT REVIEW/MERGE] Swagger for Lease Container API from Oct17 to latest

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

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


text:
[AutoPR cognitiveservices/data-plane/AnomalyDetector] Fix Go SDK for cognitiveservices/anomalydetector

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

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


text:
[QUERY] Copy data from one storage account to another storage account across subscription

Query/Question
Copy data from one storage account to another storage account across subscription using azure java sdk.
Why is this not a Bug or a feature Request?
We need to copy a virtual directory content to another storage account through code. AzCopy provides this option by using this :
azcopy copy 'https://source-storage-account-name.blob.core.windows.net/container-name/directory-path SAS-token'
'https://destination-storage-account-name.blob.core.windows.net/container-name' --recursive
Is the same option available in azure java sdk. Currently we are using startCopy .
Limitation of this method is we need to pass files in directory one by one.
It is time consuming process. We want to avoid looping through the files and just copy all the data from virtual directory in recursive way to destination.
Setup (please complete the following information if applicable):

OS: [e.g. iOS]
IDE : STS
Version of the Library used :

com.azure
azure-storage-blob
12.6.0

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

[ ] Query Added
[ ] Setup information Added

The sdk does not have a method to bulk copy a directory from one location to another, and there are not plans to add such a method. As you mentioned, azcopy includes this feature, and our recommendations in these scenarios is always to use azcopy as it is finely tuned for exactly this workload. If you want this feature within Java, it will be up to you to build the solution as you mentioned.

Closing this issue as it is not a feature we plan to add and it has been left idle for a while.

authors: rickle-msft saralpa

repo: Azure/azure-sdk-for-java


text:
Support strongly-typed getDocument API

.NET/JS  support strongly-typed getDocument API in search. Java will have the same API for convenience.

This has been done.


text:
[BUG] spring.factories is not published with final azure-spring-data-cosmos artifact

Describe the bug
The spring.factories file that contains....
org.springframework.data.repository.core.support.RepositoryFactorySupport=com.azure.spring.data.cosmos.repository.support.CosmosRepositoryFactory
is not getting published with the azure-spring-data-cosmos artifact.
The main side effect of this that I have noticed is that the library does not work alongside other spring-data modules. In my case I was using it along side spring-data-jpa with a relational database. Not having this in place causes bean instantiation exceptions on startup. Spring has code internally that detects if multiple spring data modules are registered and it does this by seeing how many classes that extend RepositoryFactorySupport it has in the factories loader (CosmosRepositoryFactory extends RepositoryFactorySupport). Specifically this code...
boolean multipleModulesFound = SpringFactoriesLoader
      .loadFactoryNames(RepositoryFactorySupport.class, resourceLoader.getClassLoader()).size() > 1;

Without the spring.factories file in place, the above code does not detect CosmosRepositoryFactory and thinks spring-data-jpa is the only module registered. This sends spring down a different code path that only allows a single RepositoryFactoryBean instance to be instantiated instead of a RepositoryFactoryBean for each type of spring-data-module.
Exception or Stack Trace
The error that is raised when you try to use azure-spring-data-cosmos alongside another spring data module will look like this (in this case its used alongside spring-data-jpa)...
Cannot register bean definition [Root bean: class [org.springframework.data.jpa.repository.support.JpaRepositoryFactoryBean]
preceded by....
There is already [Root bean: class [com.azure.spring.data.cosmos.repository.support.CosmosRepositoryFactoryBean]
If the spring.factories file was in the artifact, spring would detect that multiple spring-data modules are registered and it would allow both of these beans to exist.
To Reproduce
Use azure-spring-data-cosmos alongside one other spring-data module like spring-data-jpa or spring-data-mongo
Expected behavior
The spring.factories file that already exists in the project here...
https://github.com/Azure/azure-sdk-for-java/blob/master/sdk/cosmos/azure-spring-data-cosmos/src/main/resources/META-INF/spring.factories
should be published with the azure-spring-data-cosmos artifact
Workaround
Add the spring.factories file to your own project
Setup (please complete the following information):

OS: any
IDE : any
3.1.0

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

@mbhaskar - please take a look at this.

authors: Blackbaud-EricSlater kushagraThapar


text:
Update precommit_local_build.py to Support Targeting ci*.yml Files

Update precommit_local_build.py to be able to target ci*.yml files. This will allow it to more closely emulate what CI does without needing to list individual POMs or artifacts and just target a single file.

Closing as being able to run against a local YML isn't very useful


text:
[Core-HttpClient] Possible of invent our own LazySingleton pattern

Refer to https://github.com/Azure/azure-sdk-for-java/pull/23123#discussion_r817942467
We might be able to create our own singleton pattern for httpclient.

Closing as this is such a seldomly needed feature it's better to just copy to new locations.

authors: alzimmermsft mssfang


text:
Javadocs: Cleanup invalid Javadocs

Some of the Javadocs in the track two library are using invalid syntax resulting in Javadoc generation to fail.
https://github.com/Azure/azure-sdk-for-java/blob/master/common/azure-common/src/main/java/com/azure/common/credentials/AsyncServiceClientCredentials.java#L14
https://github.com/Azure/azure-sdk-for-java/blob/master/common/azure-common/src/main/java/com/azure/common/annotations/ReturnValueWireType.java#L19
https://github.com/Azure/azure-sdk-for-java/blob/master/common/azure-common/src/main/java/com/azure/common/http/policy/AsyncCredentialsPolicy.java#L22

We should investigate splitting the javadoc generation between track one and track two, such that track two is set to fail build on warning or error, and that all lint checking is enabled.

Another option is to opt-in to stricter checking in track two pom files (like we do with spotbugs / checkstyle), or opt-out of it in the track one files. I would say opting-out in track one is the better option.

Javadoc plugin documentation for reference

Fixed as part of https://github.com/Azure/azure-sdk-for-java/pull/3863

authors: JonathanGiles alzimmermsft srnagar


text:
Transport Type in Azure Service bus JAVA-SDK AMQP and AMQP WEBSOCKET

Their is no any documentation for JAVA-SDK where can identify which transport Type is better in azure Service bus.
What is Pros and Cons for both Transport type in JAVA-SDK.
Which one is better in particular application?

Thanks for this feedback @YogeshwarPrajapatiTR.  @sandeep-sen could you please follow up on this question and the feedback regarding the documentation?
/cc @Azure/azsdk-sb-java @JonathanGiles as fyi

is their any update on this?

Hi @YogeshwarPrajapatiTR,
Sorry for the long wait for a response. You are right that we currently don't have any documentation going over the Pros and Cons of Service Bus communications over raw TCP or WebSockets. We'll work to rectify this hole in our documentation but in the meantime let me offer some information on the topic here.
AMQP communications over raw TCP will be faster, but not by a large amount.
AMQP over WebSockets uses standard HTTP ports which sometimes works better in enterprise environments with port blocks. AMQP over WebSockets is also needed when using a proxy. It will be slightly slower but not by an amount considered impactful for most scenarios.
Please let me know if the explanation above answers your question.

Hi @YogeshwarPrajapatiTR,
Which option is better will depend on your particular situation. If the faster option is better, then AMQP over raw TCP will be better. Raw TCP is slightly faster than WebSockets. If the application will run behind a firewall, then it may be better to use WebSockets since it uses common ports and will work when using a proxy.


text:
Migrate test recording, for mgmt-plane

link https://github.com/Azure/azure-sdk-for-java/issues/33342
We'd need to check if these work

normal recording
recording with random name/guid (i.e. they are saved to json, and loaded at playback)
redact of secret (need to know whether we can still run script to redact it, before e.g. upload to somewhere we no longer control; or we can use TestBase to redact); if now request body is also recorded, we may need to add more redact rules

We may try

resources (random name)
storage (secret)
appservice or ACI/ACR (different kind of secret)

We also need to see if we can still batch modify api-version in recorded data, after phase2
We need this e.g. after upgrade resources RP or network RP
https://github.com/Azure/azure-sdk-assets/blob/main/README.md
e.g. upgrade Network would modify more tests https://github.com/Azure/azure-sdk-for-java/issues/34243#issue-1644850586

Another question on the "azure-sdk-assets" repo is: how it handles different recording from different branch (e.g. one branch may release a preview api-version, but main on stable)

on redact
So it has gotten better. We now have TestProxySanitizers to handle the redaction.
A lot of default redaction are already placed here https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/core/azure-core-test/src/main/java/com/azure/core/test/utils/TestProxyUtils.java#L144

On top of tha, we can do custom redactions too.
Examples - https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/core/azure-core-test/src/test/java/com/azure/core/test/TestProxyTests.java#L64-L67

Most recording would be under "sdk/resourcemanager".
Very few other places, as mgmt recommend live tests for simpler RP
One of them:
https://github.com/Azure/azure-sdk-for-java/tree/main/sdk/confidentialledger/azure-resourcemanager-confidentialledger/src/test/resources/session-records

You can contact samvaity, if more question.

Reference links:
issue on test proxy: https://github.com/Azure/azure-sdk-for-java/issues/33342
example pr: https://github.com/Azure/azure-sdk-for-java/pull/33902

Met issue on connecting to local test proxy server. Question here: https://github.com/Azure/azure-sdk-for-java/issues/33342#issuecomment-1504739305

Started working on azure-resourcemanager-resources

Testproxy migration: https://github.com/Azure/azure-sdk-for-java/wiki/Test-Proxy-Migration
sample pr: https://github.com/Azure/azure-sdk-for-java/pull/35186
resources pr: https://github.com/Azure/azure-sdk-for-java/pull/35476/files

Todos:

try remove TextReplacementPolicy
retry-after = 0, make sure long lro can run successfully
storage, response body secret sanitize
credcheck before push to asset repo.
migration for other RPs.

authors: haolingdong-msft weidongxu-microsoft


text:
Allow Generating a From Source POM Without Updating Dependency Versions

Description
This PR allows the generate_from_source_pom.py script to generate a From Source POM without needing to update dependency versions. This allows for easier debugging when there are issues with the From Source POM generation.
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.

/azp run java - core

From Source POM

@alzimmermsft Hi, I am confused about the From Source POM. I am wondering if you can give me a whole picture about what it means and where it is used?  When will I use it and how can I check if the result is correct or not? Some  backgrounds are also helpful. I have read the comments but not really totally understand it. Thank you very much.

authors: alzimmermsft jialigit


text:
Fix issues in bom and pom files

This PR will:

Replace sdk dependencies in spring-cloud-azure-dependencies with azure-sdk-bom.
Remove unnecessary enforcer dependencies
Remove unused netty dependencies from jms starter
Remove unused mongo from autoconfigure

@jialigit please update the migration guide of the jms starter, to include a section like this https://github.com/microsoft/spring-cloud-azure/blob/4.0.0-beta.4/docs/src/main/asciidoc/_migration-guide-for-4.0.adoc#dependency-changes-2. To give people some hints that we've removed the netty dependencies from the jms starter.

May explain the reason why do these changes ,  benefits and drawbacks? Maybe we should keep a checklist to check it always as we go.

May explain the reason why do these changes , benefits and drawbacks? Maybe we should keep a checklist to check it always as we go.

Spring Boot will manage the netty versions, but the qpid version we are using here depends on a older version of netty, if users depend on both jms starter and other sdk starter, the netty version comes with SDK will be omitted for conflicting with netty version comes with qpid.
So here we can't remove the netty from the jms starter, I will rollback the change.

authors: jialigit saragluna


text:
[Cosmos] version changes for release

Version changes for 4.35.2 release today.

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

authors: azure-sdk simorenoh


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:
[Service Bus] ServiceBusMessage to expose all AMQP details

Motivation for this change:
A desire to allow reading and writing of the different parts of an AMQP message as described by the AMQP spec. This gives us the interopability feature when one uses a different client that does support writing to these parts, but then uses our libraries to read the message. See "Message Format" in section 3.2 of the AMQP spec
Guiding factors for the proposal:

Existing users used to accessing either AMQP properties like messageId or AMQP message annotations like partitionKey or AMQP message header like deliveryCount should continue to have these as top level entities
All inner details of AMQP message should be accessible to the advanced user. Since these do not matter to the most of the user segment, these details need not be at the top level. Therefore, we would like to hide the details (header, footer, message annotations, deliver annotations, properties) in a nested field. This model can be replicated in Event Hubs in the future
We do not want to introduce any new AMQP message detail as a top level entity at this moment in time to avoid increasing the surface area and potential confusion due to introduction of new elements. If the service team determines that an AMQP message detail from header/footer/message annotations/delivery annotations deserves to get a spot on the top level, it should be do-able incrementally in a non breaking fashion

Proposal 1: Add AMQPMessageDetails to both sendable message and the received message
export interface ServiceBusMessage {
  body: any;
  contentType?: string;
  correlationId?: string | number | Buffer;
  subject?: string;
  messageId?: string | number | Buffer;
  partitionKey?: string;
  applicationProperties?: { [key: string]: any };
  replyTo?: string;
  replyToSessionId?: string;
  scheduledEnqueueTimeUtc?: Date;
  sessionId?: string;
  timeToLive?: number;
  to?: string;
  viaPartitionKey?: string;
  amqpMessageDetails: AMQPMessageDetails;
}

export interface AMQPMessageDetails {
  header?: AMQPMessageHeader;
  footer?: { [key: string]: any };
  messageAnnotations?: { [key: string]: any };
  deliveryAnnotations?: { [key: string]: any };
  properties: AMQPMessageProperties;
}

Proposal 2

AMQPAnnotedMessage is the representation of the AMQP message as per the spec
ServiceBusMessage is the "convenience layer" over the AMQPAnnotatedMessage pulling limited things to the top level that are familiar to SB users and ignoring other details
Both ServiceBusMessage  and AMQPAnnotedMessage are sendable messages. Most users will use the former, advanced users familiar with AMQP and wanting to tweak inner details can use the latter
Received message will expose the AMQPAnnotatedMessage via a new field
When wanting to resend a ReceivedMessage, one can send the entire message or the inner AMQPAnnotatedMessage

export interface ServiceBusMessage {
  body: any;
  contentType?: string;
  correlationId?: string | number | Buffer;
  subject?: string;
  messageId?: string | number | Buffer;
  partitionKey?: string;
  applicationProperties?: { [key: string]: any };
  replyTo?: string;
  replyToSessionId?: string;
  scheduledEnqueueTimeUtc?: Date;
  sessionId?: string;
  timeToLive?: number;
  to?: string;
  viaPartitionKey?: string;
}

export interface AmqpAnnotatedMessage {
  header?: AMQPMessageHeader;
  footer?: { [key: string]: any };
  messageAnnotations?: { [key: string]: any };
  deliveryAnnotations?: { [key: string]: any };
  applicationProperties?: { [key: string]: any };
  properties?: AMQPMessageProperties;
  bodyType: "data" | "value" | "sequence",
  body: any;
}

export interface ReceivedMessage extends ServiceBusMessage {
  deadLetterReason?: string;
  deadLetterErrorDescription?: string;
  lockToken?: string;
  deliveryCount?: number;
  enqueuedTimeUtc?: Date;
  expiresAtUtc?: Date;
  lockedUntilUtc?: Date;
  enqueuedSequenceNumber?: number;
  sequenceNumber?: Long;
  deadLetterSource?: string;
  amqpMessageDetails: AmqpAnnotatedMessage;
}

sendMessages(msgs: ServiceBusMessage | ServiceBusMessage[] | ServiceBusMessageBatch | AmqpAnnotatedMessage | AmqpAnnotatedMessage[], options)
export interface ServiceBusMessageBatch {
   (all the usual stuff)
   tryAdd(msg: ServiceBusMessage | AmqpAnnotatedMessage): boolean;
}

Interfaces common to both proposals:
export interface AMQPMessageHeader {
  firstAcquirer?: boolean;
  deliveryCount?: number;
  timeToLive?: number;
  durable?: boolean;
  priority?: number;
}

export interface AMQPMessageProperties {
  messageId?: string | number | Buffer;
  to?: string;
  correlationId?: string | number | Buffer;
  contentType?: string;
  contentEncoding?: string;
  absoluteExpiryTime?: Date;
  creationTime?: number;
  groupId?: string;
  groupSequence?: number;
  replyTo?: string;
  replyToGroupId?: string;
  subject?: string;
  userId?: string;
}

With proposal 1, there are attributes with the same value at multiple places.
export interface ServiceBusMessage {
 ...
 amqpMessageDetails: AMQPMessageDetails;
}

Consider the case while sending a receivedMessage using the sendMessages API, user might tweak the top level "body" property or the one on the amqpMessageDetails. Even if we set the precedence, it might be confusing for the users.

Proposal 1: Consider the case while sending a receivedMessage using the sendMessages API, user might tweak the top level "body" property or the one on the amqpMessageDetails. Even if we set the precedence, it might be confusing for the users.

Isn't we discussed that there is always one variable/source  for a property 'value' and that gets changed whether user change at top level or in amqpMessageDetails ?  User can change a value at any level and it will update one source.
95% (Whatever that number is) : A user will stay at top level and change values is needed.  And  Advance users can change any where but it will update same one variable for that property.
Proposal 2 : Like Connie mentioned, it will multiply overloads by two.

Proposal 2 : Like Connie mentioned, it will multiply overloads by two.

Yes, in .Net & Java that would be the case. But Python & JS can use union of types

Isn't we discussed that there is always one variable/source for a property 'value' and that gets changed whether user change at top level or in amqpMessageDetails ? User can change a value at any level and it will update one source.

@hemanttanwar The problem is.. we can't stop a user from constructing a message object with two different "body"s in JS, which is not a problem in Java or .NET.

I'm a fan of approach 2, personally. Although, since ReceivedMessage is a subtype of ServiceBusMessage, it would be nice if their names are related similarly. ReceivedServiceBusMessage seems pedantically correct but maybe too long. Open to other suggestions, or keeping the current names if no alternatives are palatable.

I'm a fan of approach 2, personally. Although, since ReceivedMessage is a subtype of ServiceBusMessage, it would be nice if their names are related similarly. ReceivedServiceBusMessage seems pedantically correct but maybe too long. Open to other suggestions, or keeping the current names if no alternatives are palatable.

We call it ServiceBusReceivedMessage in .NET.

In #10957, we added a new field to hold all the inner AMQP details of the message when it is received. This allows someone using another client library to set such inner details to then use our libraries to receive the message and read these details.
Logged #11102 to track the need to have similar changes on the sending side.

authors: HarshaNalluru JoshLove-msft bterlson hemanttanwar ramya-rao-a

repo: Azure/azure-sdk-for-js


text:
Add Schema Registry Performance Tests

Add Performance tests for the performance-critical champion scenarios of Schema Registry SDK.
Performance Test Writing Guidelines:
https://github.com/Azure/azure-sdk-for-js/wiki/Writing-Performance-Tests

closing in favor of #16983


text:
[Storage] Duplicated tests and Uncovered code flows

Duplicated tests in different files (example below)
https://github.com/Azure/azure-sdk-for-js/blob/ad6fb87c1036fb606a68843a47e3bdd884622046/sdk/storage/storage-queue/test/node/messagesclient.spec.ts#L103
https://github.com/Azure/azure-sdk-for-js/blob/ad6fb87c1036fb606a68843a47e3bdd884622046/sdk/storage/storage-queue/test/node/messageidclient.spec.ts#L96

Duplicated tests in the same file messageidclient.spec.ts with different titles [same with messagesclient.spec.ts]
https://github.com/Azure/azure-sdk-for-js/blob/ad6fb87c1036fb606a68843a47e3bdd884622046/sdk/storage/storage-queue/test/node/messageidclient.spec.ts#L151
https://github.com/Azure/azure-sdk-for-js/blob/ad6fb87c1036fb606a68843a47e3bdd884622046/sdk/storage/storage-queue/test/node/messageidclient.spec.ts#L162

https://github.com/Azure/azure-sdk-for-js/blob/ad6fb87c1036fb606a68843a47e3bdd884622046/sdk/storage/storage-queue/src/MessageIdClient.ts#L147 To my understanding - queueName + "/" + messageId should be queueName + "/messages/" + messageId and maybe this bug didn't unravel since we may not have covered the code path in tests and samples

[ ] Verify the code coverage and see if we have missed any untested workflows.
[x] MessageIdClient doesn't have tests for its constructors covering all the scenarios
[x] Remove/update the duplicated tests case by case.
[x] Fix the bug -> queueName + "/" + messageId should be queueName + "/messages/" + messageId
[x] Add/update tests to cover the above code path

/cc - @XiaoningLiu

Closing the issue


text:
[search] unify on what to do about GeographyPoint / consider moving to Core

GeoJSON point data is represented in other languages as a common type. We implemented a simple GeographyPoint type in preview 1, but we should look at what cosmos did and consider creating a generic class / interface in Core.

Cosmos for JS doesn't seem to have this type, so I don't think we have to worry here.
/cc @southpolesteve in case it's on the horizon

I don't think there is an overlap. We have some new spatial indexing stuff (
https://github.com/Azure/azure-sdk-for-js/blob/8c4020efdce34caee5061bf09f66adb55b648a89/sdk/cosmosdb/cosmos/src/documents/IndexingPolicy.ts#L16-L39
)
, but the types in the actual document are still just strings
On Thu, Mar 26, 2020 at 7:05 PM Jeff Fisher notifications@github.com
wrote:

Closed #7844 https://github.com/Azure/azure-sdk-for-js/issues/7844.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-sdk-for-js/issues/7844#event-3170504336,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADTC2GYDN6WN3KGH6VQ6LTRJPUWDANCNFSM4LMXD4GQ
.

Thank you @southpolesteve for the confirmation!

authors: southpolesteve xirzec


text:
[Servicebus] Cleanup Eslint Errors and Report Generation

Fixing eslint errors for servicebus
Eslint html report generation

@Azure/azure-sdk-eng @bterlson @ramya-rao-a

@KarishmaGhiya There are few conflicting files in this PR, can you resolve the merge conflicts before we start reviewing?

@ramya-rao-a This is ready for review

I'm assuming we don't actually want to commit the report.html files?

@KarishmaGhiya I have responded to all the queries regarding return types. Is it possible to not have the changes related to moving the private functions before the public ones in this PR and relax the rule for that? It would make reviewing this PR easier. We can tackle that rule in a separate PR

authors: KarishmaGhiya bsiegel ramya-rao-a


text:
adated link to types

Packages impacted by this PR
/health-insights-radiologyinsights
Issues associated with this PR
documentation not created
Describe the problem that is addressed by this PR
wrong link in package.json

/azp run js - healthinsights

/azp run js - healthinsights

/azp run js - healthinsights


text:
[AutoPR machinelearningcompute/resource-manager] chore: jsonfmt machinelearningcompute

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

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


text:
Design approach to exposing supervised field types in common ExtractedField type

For fields under DocumentResult, we'll want to expose both the field's text (directly from the form) and the strongly typed value (like DateTime, int, float, etc).  How can we do that without making the fields under ExtractedPage too complicated?
We might consider designing different, more advanced APIs for this.  We should work to deeply understand the customer scenario for this if we choose to do this.
Look for opportunity to use arch board guidance on custom serialization: https://github.com/Azure/azure-sdk/issues/997

[ ] For phone numbers

[ ] For floats

[ ] For ints

Additional comments from the FR APIView:
public class ExtractedReceipt {

| public IReadOnlyDictionary<string, ExtractedReceiptField> ExtractedFields { get; }
| public IReadOnlyList Items { get; }
| public string MerchantAddress { get; }
ctstone1 day agoCould we use generics for field values so that I can access the Value, Text, Confidence, and BoundingBox properties without using the dictionary ?

Won't do for preview 1.

Updated in new design.

repo: Azure/azure-sdk-for-net


text:
[QUERY] How can I specify BOTH lease Id and overwrite=true in BlobClient.UploadAsync

Library name and version
Azure.Storage.Blobs 12.10.0
Query/Question
There's an overload with bool overwrite and there's one with BlobUploadOptions which can be used to set conditions with lease.
I need to do both at once, how can I do that? If I specify only lease id, I get exception, that Blob already exists
Environment
No response

I have same question. Suggestion is to use specialized BlockBlobClient but I've not yet attempted.
https://stackoverflow.com/questions/71428072/how-to-set-overwrite-in-azure-blobclient-when-using-blobuploadoptions?noredirect=1#comment126252078_71428072

authors: atsapura golfalot


text:
Apply splitting to Azure Monitor metrics query with Azure.Monitor.Query

Library name and version
Azure.Monitor.Query 1.1.0
Query/Question
Is it possible to do splitting with Azure.Monitor.Query SDK when retrieving Monitor metrics?
I'm trying to retrieve metrics for a service bus account, split by EntityName. This is possible in the portal:

This is the code that I have. I can retrieve the metrics but don't know how to apply the splitting.
var credential = new ClientSecretCredential(_tenantId, _clientId, _clientSecret);
var metricsClient = new MetricsQueryClient(credential);
var resourceId = $"/subscriptions/{_subscriptionId}/resourceGroups/{_resourceGroupName}/providers/Microsoft.ServiceBus/namespaces/{_serviceBusName}";
var metrics = new[] { "ScheduledMessages", "ActiveMessages" };

var options = new MetricsQueryOptions();
options.Aggregations.Add(MetricAggregationType.Total);
options.TimeRange = TimeSpan.FromHours(4);

var result = await metricsClient.QueryResourceAsync(resourceId, metrics, options);

Environment
IDE: Visual Studio 17.5.3.
dotnet --info results:
.NET SDK:
 Version:   7.0.202
 Commit:    6c74320bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.202\

Host:
  Version:      7.0.5
  Architecture: x64
  Commit:       8042d61b17

I am interested in the same thing, is there any update?

Good point this should be better documented. Splitting and filtering actually both use the same filter parameter the only difference is splitting is where the filter value is equal to ''.
So an example of splitting is:
$filter=ApiName eq ''
An example of filtering is:
$filter=ApiName eq 'GetBlob'

I'll get this documented in our README file

authors: ToddKingMSFT blueboxes scottaddie szilardd


text:
Unclear what SubscriptionRuntimeProperties.AccessedAt really means

Library name and version
Azure.Messaging.ServiceBus
Query/Question
The property SubscriptionRuntimeProperties.AccessedAt is supposed to return "when the entity was last accessed", but what does that mean? What constitutes access? I think it would be nice with a bit of clarification in the docs.
More specifically, is this the value that is used when calculating idle time for the  "auto-delete on idle" mechanism? We want to implement a warning notification system, which can alert us on pending deletions.
Environment
No response

Hi @gliljas.  Thank you for reaching out and for your inquiry.  Unfortunately there is no official Service Bus service documentation that details what "access" indicates, but it looks from the legacy package docs that "access" for a subscription means that there was a receive request for it.

Thanks for the link to the legacy docs, @jsquire! Since it's a service side property I should be the same in the new library, and it's quite likely exactly what we wanted.

authors: gliljas jsquire


text:
Provide cert autorotation support in the auth library

Currently Auth library has no support for the newly added cert auto rotation.
Redis team needs this to unblock their scenario.

This feature has been delayed due to customer requirement.
The work has been checked into a separate branch
https://github.com/shahabhijeet/azure-sdk-for-net/commit/cde8a1f3f93b5ad71e1ec29bbd34ef1014696f9e


text:
Implement a wait backoff for Key Vault LROs

Consider implementing a backoff on the polling interval for some or all Key Vault LROs. This might be most helpful for CertificateClient.StartCreateCertificate that can take a long time - even days while waiting for human intervention.

Should we consider adding an additional method to OperationHelpers similar to
https://github.com/Azure/azure-sdk-for-net/blob/66de0fc0f20a3a888716df5e1075d8893b2e1899/sdk/core/Azure.Core/src/Shared/OperationHelpers.cs#L42
For example
public static async ValueTask<Response<TResult>> PolicyWaitForCompletionAsync<TResult>(this Operation<TResult> operation, WaitPolicy policy, CancellationToken cancellationToken)

where WaitPolicy is similar to RetryOptions?

Probably a better question for @pakrym, but with the second, why not just use RetryOptions, which means we could take whatever the user specified or use the defaults if none. Most of it is relevant.

Agreed about RetryOptions with the exception of maybe NetworkTimeout

I would start by using RetryOptions directly. I know it has some extra members but considering the usage is fully internal it shouldn't be a problem.
public static async ValueTask<Response<TResult>> WaitForCompletionAsync<TResult>(this Operation<TResult> operation, RetryOptions options, CancellationToken cancellationToken)
We also need to make sure reties do not escalate to very large values too quickly.

This is still an issue. If I force a 429, I don't get a Retry-After header, though, so we'd need to artifically implement a wait back-off. @jlichwa it would be nice if the service did that, which is generally a good idea when sending a 429 (too many requests):
Status: 429
Content:
{"error":{"code":"Throttled","message":"Request was not processed because too many requests were received. Reason: VaultRequestTypeLimitReached"}}

Headers:
Cache-Control: no-cache
Pragma: no-cache
x-ms-keyvault-region: westus2
x-ms-client-request-id: dd86cbb5-58fe-49fd-a04a-d9eb358a18c1
x-ms-request-id: 1ee55031-971a-4396-a66a-06d394dba343
x-ms-keyvault-service-version: 1.9.576.1
x-ms-keyvault-network-info: conn_type=Ipv4;addr=24.16.19.131;act_addr_fam=InterNetwork;
X-Content-Type-Options: REDACTED
Strict-Transport-Security: REDACTED
Date: Tue, 01 Nov 2022 21:49:18 GMT
Content-Length: 146
Content-Type: application/json; charset=utf-8
Expires: -1

@heaths is this still valid?

Valid, yes, but whether we should do anything about it in the SDK, I still think not. I think the service team should implement Retry-After so that it works with any REST client that respects it. /cc @jackrichins

Given this is something we would want the service team to implement - should we open a feature request with the KV team and close this issue? I don't think there is any action item that we want to take on the SDK side for this and I suspect KV team would not be looking at the GH repo for prioritization/asks.

It is labeled as Service Attention that used to work, but maybe a tracking issue in their AzDO instance would be best, yes.

authors: christothes heaths pakrym pallavit


text:
AmqpMessageConverter cleanup and dispose of message

Additional split of https://github.com/Azure/azure-sdk-for-net/pull/19683
All SDK Contribution checklist:
This checklist is used to make sure that common guidelines for a pull request are followed.

[x] Please open PR in Draft mode if it is:

Work in progress or not intended to be merged.
Encountering multiple pipeline failures and working on fixes.

[ ] 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.
[x] I have read the contribution guidelines.
[x] The pull request does not introduce breaking changes.

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

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

SDK Generation Guidelines

[ ] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code. (Track 2 only)
[ ] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK. Please double check nuget.org current release version.

Additional management plane SDK specific contribution checklist:
Note: Only applies to Microsoft.Azure.Management.[RP] or Azure.ResourceManager.[RP]

[ ] Include updated management metadata.
[ ] Update AzureRP.props to add/remove version info to maintain up to date API versions.

Management plane SDK Troubleshooting

If this is very first SDK for a services and you are adding new service folders directly under /SDK, please add new service label and/or contact assigned reviewer.
If the check fails at the Verify Code Generation step, please ensure:

Do not modify any code in generated folders.
Do not selectively include/remove generated files in the PR.
Do use generate.ps1/cmd to generate this PR instead of calling autorest directly.
Please pay attention to the @microsoft.csharp version output after running generate.ps1. If it is lower than current released version (2.3.82), please run it again as it should pull down the latest version,

Old outstanding PR cleanup
Please note:
If PRs (including draft) has been out for more than 60 days and there are no responses from our query or followups, they will be closed to maintain a concise list for our reviewers.

Anything you want me to address here before this is ready?

/azp run net - servicebus - tests

Moved out the alias cleanup into a dedicated PR
https://github.com/Azure/azure-sdk-for-net/pull/19938

authors: JoshLove-msft danielmarbach


text:
Sync .github/workflows directory with azure-sdk-tools for PR 6507

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

overriding check-enforcer as there's nothing that'll run in any language pipeline that'll test these changes

/check-enforcer override

authors: JimSuplizio azure-sdk


text:
Autorest Regen Preview to 3.0.0-alpha.20230728.1 by Dapeng Zhang from refs/pull/3354/merge

Triggered from https://github.com/Azure/autorest.csharp/pull/3354

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


text:
[AzureMonitorExporter] refactor how EnvironmentVariables are read

Change our Platform abstraction to read all environment variables at once.
Environment Variables are only read as part of sdk initialization.
After initialization, the platform object is disposed.
This also protects us from needing to use try/catch every time we get an environment variable.
Changes

DefaultPlatform will now collect all environment variables at once.
remove public IDictionary GetEnvironmentVariables(); from IPlatform.
This is no longer needed.

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

Debugging an unrelated issue and found this:

My changes in this PR would help avoid unnecessary exceptions.

authors: TimothyMothra azure-sdk


text:
Failed Autorest Regen Preview to 3.0.0-alpha.20240307.4 by Mingzhe Huang from refs/pull/4363/head

Triggered from https://github.com/Azure/autorest.csharp/pull/4363

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

close in favor of https://github.com/Azure/azure-sdk-for-net/pull/42534

authors: archerzz azure-sdk


text:
update keyvault_secrets readme

Purpose : update keyvault_secrets readme based on preview3.
Total changes : 3
1. Wrong code snippet "New Secret"
Original

Proposal

2. Incorrect property provided of "updateSecret.Vaule"
Original

Proposal

3. Incorrect hyperlink provided of API reference documentation

API reference documentation : https://azure.github.io/azure-sdk-for-net/api/KeyVault/Azure.Security.KeyVault.Secrets.html
Proposal
API reference documentation : https://azure.github.io/azure-sdk-for-net/api/Azure.Security.KeyVault.Secrets.html

Can one of the admins verify this patch?

Yes, all changes mentioned above are in preview 4.

preposals already applied to readme. Close PR.

authors: azuresdkci heaths tzhanl


text:
ResourceNotFoundError (404) with DocumentIntelligenceClient

Environment:

Python Version: 3.9.13
Old SDK: azure-ai-formrecognizer 3.3.2
New SDK: azure-ai-documentintelligence 1.0.0b1

Issue:
I am facing a ResourceNotFoundError (404) when using DocumentIntelligenceClient in the new Azure SDK version 1.0.0b1. The old SDK version 3.3.2 (DocumentAnalysisClient) works fine with the same endpoint and key.
Reproducible Steps:

Working Code with Old SDK (azure-ai-formrecognizer 3.3.2):
from azure.core.credentials import AzureKeyCredential
from azure.ai.formrecognizer import DocumentAnalysisClient

endpoint = os.environ["ENDPOINT"]
key = os.environ["API_KEY"]

client = DocumentAnalysisClient(endpoint=endpoint, credential=AzureKeyCredential(key))
with open(path_to_sample_documents, "rb") as f:
    poller = client.begin_analyze_document("prebuilt-layout", f)

Non-Working Code with New SDK (azure-ai-documentintelligence 1.0.0b1):
from azure.core.credentials import AzureKeyCredential
from azure.ai.documentintelligence import DocumentIntelligenceClient

endpoint = os.environ["ENDPOINT"]
key = os.environ["API_KEY"]

client = DocumentIntelligenceClient(endpoint=endpoint, credential=AzureKeyCredential(key))
with open(path_to_sample_documents, "rb") as f:
    poller = client.begin_analyze_document("prebuilt-layout", f)

Error Message:
azure.core.exceptions.ResourceNotFoundError: (404) Resource not found

Hi @ffalkenberg , thanks for contacting!

Are you using the same resource in the old and new SDK?
Can you provide stack trace which could help us to investigate?

I'm also running into the exact same issue. I'm using the same resource with both the old and the new client. Only the new client returns a 404.

Hi @ffalkenberg and @calmdown13 ,
You have to override the default content_type while analyzing a local doc in our first beta release azure-ai-documentintelligence 1.0.0b1.
Can you try the code below?
from azure.core.credentials import AzureKeyCredential
from azure.ai.documentintelligence import DocumentIntelligenceClient

endpoint = os.environ["ENDPOINT"]
key = os.environ["API_KEY"]

client = DocumentIntelligenceClient(endpoint=endpoint, credential=AzureKeyCredential(key))
with open(path_to_sample_documents, "rb") as f:
    poller = client.begin_analyze_document("prebuilt-layout", f, content_type="application/octet-stream")

@YalinLi0312 Hi, I used your code from above with content_type but still get the error, here is my stack trace
Traceback (most recent call last):
  File "/path/to/my/project/test.py", line 18, in <module>
    poller = client.begin_analyze_document("prebuilt-layout", f, content_type="application/octet-stream")
  File "/path/to/python-environment/site-packages/azure/core/tracing/decorator.py", line 78, in wrapper_use_tracer
    return func(*args, **kwargs)
  File "/path/to/python-environment/site-packages/azure/ai/documentintelligence/_operations/_operations.py", line 752, in begin_analyze_document
    raw_result = self._analyze_document_initial(  # type: ignore
  File "/path/to/python-environment/site-packages/azure/ai/documentintelligence/_operations/_operations.py", line 510, in _analyze_document_initial
    map_error(status_code=response.status_code, response=response, error_map=error_map)
  File "/path/to/python-environment/site-packages/azure/core/exceptions.py", line 164, in map_error
    raise error
azure.core.exceptions.ResourceNotFoundError: (404) Resource not found
Code: 404
Message: Resource not found

@YalinLi0312 Same as @ffalkenberg. Still a 404 even after overriding the content_type.

@calmdown13  @ffalkenberg Do you still see 404 with the region from the available list?

FYI I think it is to do with the region, I found this here.

I ran pip install azure-ai-documentintelligence and am trying to send a blob URL that is in Blob Storage. Using Azure Function. The Doc Intel resource has Storage Blob Data Reader role assigned, but I still receive 404.
How do I know which api-version I'm using? The App Insights request shows REDACTED for api-version!
My Doc Intel resource is deployed in Central US region.

Man...what a time sink! I spun up a new Doc Intel resource in West2 US region, updated the Doc Intel endpoint, and tried again... BINGO, went through the first time.
It would be very useful if available regions are the only options when deploying a new Azure Resource! This is not the first time I've spent hours on an ambiguous error only to find that the resource is unavailable (and shouldn't even have been allowed to be created!) in the region I created it in...

Redeploy in an allowed region.

solve my problem by deployed in East US region, even with North Central US doesn't support as of now.

Change of region solved my issue as well

FYI I think it is to do with the region, I found this here.

I ran pip install azure-ai-documentintelligence and am trying to send a blob URL that is in Blob Storage. Using Azure Function. The Doc Intel resource has Storage Blob Data Reader role assigned, but I still receive 404.
How do I know which api-version I'm using? The App Insights request shows REDACTED for api-version!
My Doc Intel resource is deployed in Central US region.

Did you get the issue resolved in the redeployed region? I'm asking because I notice the role you are using may not work, we recommend to use Cognitive Services User role which is mentioned in our README.md.
For your question about how to know the api-version you're using - you can check by debugging the client or request, or check the SDK version and API version table in our README.md
Thanks

repo: Azure/azure-sdk-for-python


text:
Migrate marketplaceordering to testProxy (Do not merge)

TestProxy

/azp run

/azp run [python - marketplaceordering - ci,python - marketplaceordering - ci (Build Test windows2019_38)]

/azp run python - marketplaceordering - ci (Build Test windows2019_38)

/azp run python - marketplaceordering - ci


text:
[AutoRelease] t2-network-2022-10-24-31097(Do not merge)

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

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

/check-enforcer override

authors: azure-sdk msyyc


text:
[AutoPR consumption/resource-manager] [Hub Generated] Review request for Microsoft.Consumption to add version 2019-01-01

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

(message created by the CI based on PR content)

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


text:
Update resource deployment scripts to support deployments to sovereign clouds

remove the need to specify secrets/variables from the calling template
consolidate provisioner and test application so we have to manage fewer secrets
add support for deploying to sovereign clouds based on a variable (e.g. can be specified in matrix)

I added some comments for some more clean-up in https://github.com/Azure/azure-sdk-for-net/pull/10608

authors: danieljurek weshaggard

repo: Azure/azure-sdk-tools


text:
Update azure-sdk-build-tools Repository Resource Refs in Yaml files

Update triggered by - https://dev.azure.com/azure-sdk//internal/_build/results?buildId=3619416

/check-enforcer override

authors: azure-sdk benbp


text:
AzCopy panics when uploading 16.5 TB disk snapshot to a container in blob storage

Retrieve LMT through a helper method that handles if LMT is nil or not
Retrieve ContentLength through a helper method that handles if ContentLength is nil or not
Unit tests written to test locally and avoid lengthy testing time in CI due to large size of managed disk snapshot (7.9 TB). Must be set up locally.
Unit tests that mocks service GetProperties response

Create end-to-end test to test locally
Run this test locally
Mark test as skip, follow up with Gauri on how to do this.
Create unit test with mocks

authors: seanmcc-msft siminsavani-msft

repo: Azure/azure-storage-azcopy


text:
Third party assemblies do not load every time after idling

I'm experiencing an issue with a blobtriggered function, in which I utilize multiple third party dlls. After running succesfully for a while, it will fail to load the assemblies in the bin folder after idling. But not every time.
Provide the steps required to reproduce the problem

Listen to a blobtrigger (might be every trigger, I don't know), and call a function in a third party DLL.
Watch it fail to load the assembly after going idle, but only sometimes. This means it sometimes recovers the next time it idles.

Expected behavior

Should continue to run and start up after idling.

Actual behavior

Fails to load 3rd party dll's in the bin folder.

Related information
Function is written in C#, simply does this:
#r "Lasso.Content.dll"
#r "Lasso.Data.dll"
#r "Lasso.Functions.dll"
#r "Lasso.Domain.dll"

using System;

public static async Task Run(Stream blob, string name, TraceWriter log)
{
    try {

        await new Lasso.Functions.EventHandlerFunction().Run(name);
    } catch (Exception e)
    {
        log.Error(e.Message);
    }
}

The specific exception:
Exception while executing function: Functions.EventHandlerFunction
Microsoft.Azure.WebJobs.Host.FunctionInvocationException : Exception while executing function: Functions.EventHandlerFunction ---> System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation. ---> System.TypeLoadException : Could not load type 'Lasso.Functions.EventHandlerFunction' from assembly 'Lasso.Functions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
   at async Submission#0.Run(Stream blob,String name,TraceWriter log) at  : 17
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Submission#0.Run(Stream blob,String name,TraceWriter log)
   End of inner exception
   at System.RuntimeMethodHandle.InvokeMethod(Object target,Object[] arguments,Signature sig,Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj,Object[] parameters,Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj,BindingFlags invokeAttr,Binder binder,Object[] parameters,CultureInfo culture)
   at async Microsoft.Azure.WebJobs.Script.Description.DotNetFunctionInvoker.InvokeCore(Object[] parameters,FunctionInvocationContext context)
   at async Microsoft.Azure.WebJobs.Script.Description.FunctionInvokerBase.Invoke(Object[] parameters)
   at async Microsoft.Azure.WebJobs.Host.Executors.FunctionInvoker`1.InvokeAsync[TReflected](Object[] arguments)
   at async Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.InvokeAsync(IFunctionInvoker invoker,Object[] invokeParameters,CancellationTokenSource timeoutTokenSource,CancellationTokenSource functionCancellationTokenSource,Boolean throwOnTimeout,TimeSpan timerInterval,IFunctionInstance instance)
   at async Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.ExecuteWithWatchersAsync(IFunctionInstance instance,IReadOnlyDictionary`2 parameters,TraceWriter traceWriter,CancellationToken…

This is the same issue reported here, correct?
When did you first notice this issue? Can you share your function app name directly or indirectly so we can take a closer look?

Hi. Yep, that's me aswell.
My function app name is called Lasso-Services, the function called EventHandlerFunction. EU West.

@EmilBechMadsen looking at some logs and execution information, there are a couple of things we can do to resolve this issue:

Looks like multiple functions are using the same set of assemblies with multiple copies deployed. While this alone is not an issue, it often leads to mismatched deployments if you're dealing with multiple versions. I'd recommend deploying those assemblies to a common folder and referencing them with a relative path (e.g. #r "..\shared\myassembly.dll")
We noticed some assembly resolution subscriptions pulling from the current domain, which may also cause issues since private assemblies are loaded into a different context and you may end up with an incorrect version or interfering with the runtime logic. Those were also accumulating
Only the direct assembly reference needs to be added to your function. So you only need to #r the assembly that implements your function method and the indirect references will be automatically resolved. While this alone wouldn't cause the issue, it is the recommended practice so you don't have unnecessary metadata references

I'm still inspecting some of the data, but wanted to share those findings.

Hi Fabio. Thanks for investigating.

I'll take a swing at the shared assemblies.
Are you referring to AppDomain.CurrentDomain.AssemblyResolve in regards to resolutionsubscriptions? If so, that was just an attempt at mitigation, so I suppose we can ignore that.
Will remove second-degree #r's :)

I've now implemented above suggestions and will report back in a day or two whether that solved my problem.
If it does indeed work, I think it's because I had another version of the assembly with the same version number, but without the missing EventHandlerFunction class in another function's bin folder. I was not aware that this was a problem, and that they would sometimes run using the assembly of another function.
Something not related to this issue:
The NuGet package management really is dodgy at best. Sometimes a package will install correctly, othertimes it won't. During these changes, some packages would just refuse to install no matter what I did (even if it said it was installed and in the file system), so I ended up resorting to manually putting my otherwise NuGet-referenced dll's in the shared folder as well. This worked fine (Even with WindowsAzure.Storage v. 8.1.1).

Yes, what you've described with the mismatch could indeed cause issues.
About the NuGet, if you have more information you can share (error messages, details about the behavior, etc.) that would help. The restore process uses the same NuGet restore logic (same actual client) as what you'd see locally, the key difference (and what sometimes causes some of the issues with it) is the remote file system, but without more information, we can't really pinpoint that as the cause.

Preliminary results after 24 hours of running: It worked.
About the NuGet: I didn't really intend on you to fix it, as we all know NuGet is kind of odd sometimes. I can't really say much other than it wouldn't run because it was missing files that I had included in my project.json. When I forced a restore (by changing project.json), it would even say "Installed XXXX" (the exact missing assembly). It still wouldn't run properly. Not even after a restart of the Function app, deleting all NuGet caches or changing the version numbers back and forth.

Good to hear the original issue was resolved.
How often are you running into the NuGet issues?
It would be good to track it separately, so I'll close this issue for now, and if you run into this again, would you mind opening a new issue and sharing both, the project.json AND the project.lock.json files (as well as the errors you see)?
Thanks!

authors: EmilBechMadsen fabiocav

repo: Azure/azure-webjobs-sdk-script


text:
azurefile-dockervolumedriver for DC/OS json

Hello,
Could you please point out how could I use this azurefile-dockervolumedriver driveer for DC/OS application JSON? I cannot find any resource for this - yet.
Thanks,
Tamas

@TamasSzerb I suggest reading DCOS documentation on how to configure Docker Volume Plugins. This is just another plugin really.

@TamasSzerb  There is an example here: https://mesosphere.github.io/marathon/docs/external-volumes.html I suggest following that tutorial. It should work the same way once your Mesos agent nodes are configured with azurefile-dockervolumedriver in advance.

authors: TamasSzerb ahmetalpbalkan

repo: Azure/azurefile-dockervolumedriver


text:
BEEGFS_LOCAL_SSF #20210102.1 pipeline failure

stderr=ssh: Could not resolve hostname headnodeb8667c.southcentralus.cloudapp.azure.com: Temporary failure in name resolution
https://azurecat.visualstudio.com/hpccat/_build/results?buildId=10405&view=logs&j=6e4f1cc6-8050-5bf9-8495-3efafd6ef526&t=d55b938c-7420-5d64-4f01-a655a6be2261&l=626

Manually reran and passed

Manually reran and passed

repo: Azure/azurehpc


text:
Linter Rule to convert resourceId to existing syntax

Is your feature request related to a problem? Please describe.
Existing resources are an awesome part of bicep that are easy to look over.  Could a linter rule detect hard coded resource ids, and offer to convert them to use the existing syntax?
Describe the solution you'd like
Suggest changing the following:
var resourceId = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rgName/providers/Microsoft.Storage/storageAccounts/accountName'

to
resource resource 'Microsoft.Storage/storageAccounts@2021-04-01' existing = {
  name: 'accountName'
  scope: resourceGroup('00000000-0000-0000-0000-000000000000', 'rgName')
}

and change all other references to resourceId to resource.id

One of the most common occurrences I've countered this need is when decompiling templates generated from the portal.  So rather than / in addition to a linter rule, this could be handled by

In the portal (once it supports generating bicep templates natively)
In the decompiler

repo: Azure/bicep


text:
Features/detect headphones

Purpose

...

Does this introduce a breaking change?

[ ] Yes
[ ] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Test the code

What to Check
Verify that the following are valid

...

Other Information

Adam, noticed few bugs:

on fresh install if bluetooth is connected before, in audio device selection device is not displayed

Audio device list displays device name but button says bluetooth

@iaulakh

Added check for permission approval to init bluetooth (for android 12 Runtime permissions for bluetooth).
Fixed SetupControlBarView (Shows device name & Headset when plugged)
Removed Comment from last PR (from merge commit)
getAdapter() instead of getDefaultAdapter() (deprecated update)

@iaulakh I think good now (no memory leak) small fix for that.

authors: ahammer iaulakh

repo: Azure/communication-ui-library-android


text:
Added comments to make it more clear when we are setting the topic from the adapter

What
Added comments to make it more clear when we are setting the topic from the adapter

Please update the PR title and description before merging.

authors: carocao-msft prprabhu-ms

repo: Azure/communication-ui-library