text:
Resource group name doesn't satisfy the constraint pattern /^[-\w._()]+$/

Package Name:  @azure/arm-resources
Package Version: 4.0.0
Operating system: MacOS Catalina Version 10.15.7
[x] nodejs

version:  10.17.0

[ ] browser

name/version:

[ ] typescript

version:

Is the bug related to documentation in

[ ] README.md
[ ] source code documentation
[ ] SDK API docs on https://docs.microsoft.com

Describe the bug
I have created an Azure resource group from the portal named Instruktører.  Now I am trying to do a GET call for this resource group it is throwing me this error.
(node:57737) UnhandledPromiseRejectionWarning: Error: "resourceGroupName" with value "Instruktører" should satisfy the constraint "Pattern": /^[-\w\._\(\)]+$/.
    at failValidation (/Users/turbotindia/Documents/Azure/node_modules/@azure/arm-resources/node_modules/@azure/ms-rest-js/dist/msRest.node.js:461:19)
    at Serializer.validateConstraints (/Users/turbotindia/Documents/Azure/node_modules/@azure/arm-resources/node_modules/@azure/ms-rest-js/dist/msRest.node.js:495:21)
    at Serializer.serialize (/Users/turbotindia/Documents/Azure/node_modules/@azure/arm-resources/node_modules/@azure/ms-rest-js/dist/msRest.node.js:550:18)
    at getOperationArgumentValueFromParameterPath (/Users/turbotindia/Documents/Azure/node_modules/@azure/ms-rest-azure-js/node_modules/@azure/ms-rest-js/dist/msRest.node.js:4720:24)
    at getOperationArgumentValueFromParameter (/Users/turbotindia/Documents/Azure/node_modules/@azure/ms-rest-azure-js/node_modules/@azure/ms-rest-js/dist/msRest.node.js:4695:12)
    at ResourceManagementClient.ServiceClient.sendOperationRequest (/Users/turbotindia/Documents/Azure/node_modules/@azure/ms-rest-azure-js/node_modules/@azure/ms-rest-js/dist/msRest.node.js:4488:45)
    at ResourceGroups.get (/Users/turbotindia/Documents/Azure/node_modules/@azure/arm-resources/dist/arm-resources.js:6302:32)
    at msRestNodeAuth.interactiveLogin.then (/Users/turbotindia/Documents/Azure/resourceGroup.js:16:25)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:57737) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:57737) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

From what I understand there is an issue with a character used in the resource group name (ø).
To Reproduce
A sample code to replicate this behaviour.
const msRestNodeAuth = require("@azure/ms-rest-nodeauth");
const azureArmResources = require("@azure/arm-resources");

const subscriptionId = "<your_subscription_id>";
let resourceGroup;
// This works
// resourceGroup = "<any_other_resource_group_name>";

// This doesn't work
resourceGroup = "Instruktører";

msRestNodeAuth.interactiveLogin().then((credentials) => {
  const client = new azureArmResources.ResourceManagementClient(credentials, subscriptionId);
  client.resourceGroups.get(resourceGroup).then((result) => {
    console.log("The result is:");
    console.log(result);
  });
}).catch((err) => {
  console.error(err);
});

Expected behaviour
The resource group name Instruktører is a valid name since I have created a resource group with this name from the portal. So the SDK should accept this as a valid name and not throw an error.
Screenshots
Resource group which I created.

Additional context
N/A

@colawwj Could you take a look at this issue? Thanks

@colawwj Could you take a look at this issue? Thanks

@sdsubhajitdas
I can repro this case. Since "Instruktører" doesn't match the rest api regular exppression constraint defined https://github.com/Azure/azure-rest-api-specs/blob/master/specification/resources/resource-manager/Microsoft.Resources/stable/2020-06-01/resources.json#L2542, the JS SDK's behavior is expected as the swagger definition. Thanks

@sdsubhajitdas
I can repro this case. Since "Instruktører" doesn't match the rest api regular exppression constraint defined https://github.com/Azure/azure-rest-api-specs/blob/master/specification/resources/resource-manager/Microsoft.Resources/stable/2020-06-01/resources.json#L2542, the JS SDK's behavior is expected as the swagger definition. Thanks

Thanks for the response @colawwj.
Shouldn't this also prevent us from creating a resource group with this name Instruktører in the Azure portal, as per the regex pattern defined?

Thanks for the response @colawwj.
Shouldn't this also prevent us from creating a resource group with this name Instruktører in the Azure portal, as per the regex pattern defined?

@sdsubhajitdas
The constraint defined is vaild when you are create resourceGroup by js sdk ,but in the Azure portal ,the charactor scope is more widde.

@sdsubhajitdas
The constraint defined is vaild when you are create resourceGroup by js sdk ,but in the Azure portal ,the charactor scope is more widde.

This is a gap between the portal behavior and the swagger definition regarding the resource group name constraint. Need to involve service team for further explaination.

This is a gap between the portal behavior and the swagger definition regarding the resource group name constraint. Need to involve service team for further explaination.

@qiaozha Any update on the above issue please?

@SumitPopat, the Swagger https://github.com/Azure/azure-rest-api-specs/blob/0cc5a06b6712e644fc5d4fec5005a3c945d18a7a/specification/resources/resource-manager/Microsoft.Resources/stable/2020-06-01/resources.json#L2545 needs to be updated.
could you create an issue in https://github.com/Azure/azure-rest-api-specs

Sure, I have created one here: https://github.com/Azure/azure-rest-api-specs/issues/13136

Fixed here: https://github.com/Azure/azure-rest-api-specs/pull/13492

The buggy regex seems to be reintroduced in more recent specification files and the same bug has reproduced in at least arm-storage and arm-resources. Could you check where the regex come from and fix it for the SDK?

authors: JasonYeMSFT SumitPopat colawwj lirenhe qiaozha sdsubhajitdas tjegbejimba

repo: Azure/azure-sdk-for-js


text:
Azure Event Grid Readme Issue

Section link

Reason:
Doc error.
Suggestion:
Update to Queue

Section link

Reason:
the function doesn't exist.
Suggestion:
Update to deserializeCloudEvents
@jongio for notification.

Thanks for reporting @zzhxiaofeng
@ellismg Do you agree with the recommendation here? If no, then please provide your recommendation. After that either fix the issue or add the help wanted label so that @zzhxiaofeng and team can send a PR

source: gharchive/issue

authors: ramya-rao-a zzhxiaofeng

license: MIT

license_type: permissive

license_source: github-api


text:
Add documentation/samples for how to build clients against @azure/core-client

Need to give some examples, perhaps pointers to existing usages. Need to at least cover what goes in convenience client constructors.
Bonus: Talk about how to port to corev2

Thanks for creating this issue! Also, documentation for CommonClientOptions, since there doesn't seem to be any clear markdown files I could find anywhere (only was able to figure out to use it through asking you for the proper solution).

authors: YoDaMa xirzec


text:
Expose an API to log out the current account and clean up any related cached credential

Related to https://github.com/Azure/azure-sdk-for-net/issues/31498

To what file location does the cachePersistencePlugin function from the @azure/identity-cache-persistence package save the DeviceCodeCredential? (Mac and Windows)

We decided not to add API for this because we can't guarantee it would work as expected and there will be workarounds for clearing the cache. See https://github.com/Azure/azure-sdk-for-net/issues/32048#issuecomment-1485930145 for more information.


text:
TS2305: Module '"@azure/openai"' has no exported member 'AzureKeyCredential'.

Package Name:  @azure/openai
Package Version:  2.0.0-beta.1
Operating system: macOS
[x] nodejs

version:  20.11.0

[ ] browser

name/version:

[x] typescript

version: 5.5.4

Is the bug related to documentation in

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

Describe the bug
Trying to migrate from to version 2, getting import error:
TS2305: Module '"@azure/openai"' has no exported member 'AzureKeyCredential'.

To Reproduce
Steps to reproduce the behavior:

Install 2.0.0-beta1
Use KeyCredentials

Please look at the migration guide here: https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/openai/openai/MIGRATION.md. You will need to install @azure/identity package separately and essentially rewrite the code.

I did. I still suppose to work with Key.

I am also in the same boat (trying to upgrade from beta 1 to beta 2) but consistently getting 404 error. Posting a new bug report here shortly. Posted the same on Stack Overflow last night as well: https://stackoverflow.com/questions/78837277/resourcenotfound-error-when-connecting-to-azure-openai-using-latest-javascript-s.

You don't need to import that class, you can either set the apiKey property in the constructor call or set the AZURE_OPENAI_API_KEY environment variable.

authors: deyaaeldeen gmantri solshark


text:
Update identity version for app-config

Update identity version for app-config to 2.0.0-beta.3 and re-record required tests

@KarishmaGhiya : We only have one identity-based test in our suite (right @HarshaNalluru?), so hopefully that's enough to validate what you're doing :)

Yes, @richardpark-msft :)
That's the reason I suggested app-config when Daniel and Karishma reached out!

Addressed in this PR - https://github.com/Azure/azure-sdk-for-js/commit/99112461cdf4042ee62a6cf48d915bc5ad379870
Closing this PR

source: gharchive/pull-request


text:
[ServiceBus] add delay between infinite retry cycles

Errors that are not retryable will be re-thrown out of the normal retry() call.
However, we don't have any delay before restarting the retry cycle.
This PR adds a delay before continuing the infinite retry cycles.
Packages impacted by this PR
@azure/service-bus
Issues associated with this PR
#19883
Describe the problem that is addressed by this PR
Errors that are not retryable will be re-thrown out of the normal retry() call.
However, we don't have any delay before restarting the retry cycle.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? _
To be added
Checklists

[ ] Added a changelog (if necessary)

No, it doesn't. Might have to tweak the test.

authors: HarshaNalluru jeremymeng


text:
Update CODEOWNERS

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

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

/check-enforcer override

authors: jsquire sajeetharan


text:
Improve API docs for DAC and ChainedTokenCredential

Drive traffic to the new credential chains doc on Learn. Also, eliminate duplication in the DefaultAzureCredential API docs.

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

In the sdk/identity/identity folder, run the command rushx format

authors: KarishmaGhiya azure-sdk scottaddie


text:
[iot] Migrate @azure/iot-modelrepository to ESM/vitest

Packages impacted by this PR

@azure/iot-modelrepository

Issues associated with this PR

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

Describe the problem that is addressed by this PR
Migrates the @azure/iot-modelrepository package via automation to ESM/vitest.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

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

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

authors: azure-sdk mpodwysocki


text:
[core-amqp] Update runtime dependency "jssha"

Remove dev dependency "@types/jssha", since types have moved into the runtime package
Remove unused runtime dependency on "jssha" in "core-amqp"

jssha@3.0.0 was rewritten in TypeScript.  It should not have any breaking changes, but the major version was bumped as a precaution:
https://github.com/Caligatio/jsSHA/blob/master/CHANGELOG.md
Blocked by #9173

/azp run js - eventhubs-client - tests

/azp run js - eventhubs-processor - tests

/azp run js - servicebus - tests

/azp run js - eventhubs-processor - tests

/azp run js - eventhubs-client - tests

/azp run js - servicebus - tests

@ramya-rao-a, @xirzec: Can you please review this runtime dependency update?  I will wait until all live tests pass before merging.


text:
Make USReceiptType a simple enum

Confirm with service team that USReceiptType should not be a Flags enum, and if not, update it.
Described in comment on APIView rev 47:

[Flags]
public enum USReceiptType {

bojunehsu3 hours ago
ReceiptType is not a bit flag.
annelo-msft1 minute ago
I did this because Cha had pointed out a receipt could be both a CreditCard receipt and an Itemized receipt. Is the service not planning to return multiple values?

Does this type change need to happen for Preview 1? are other languages making the change too?

We just need to remove the [Flags] attribute from the enum.  I'm not sure other languages have this concept.

authors: annelo-msft maririos

repo: Azure/azure-sdk-for-net


text:
[BUG]

Describe the bug
Please provide the description of issue you're seeing.
Expected behavior
What is the expected behavior?
Actual behavior (include Exception or Stack Trace)
What is the actual behavior?
To Reproduce
Steps to reproduce the behavior (include a code snippet, screenshot, or any additional information that might help us reproduce the issue)

Environment:

Name and version of the Library package used: [e.g. Azure.Storage.Blobs 12.2.0]
Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): [e.g. Azure AppService or Windows 10 .NET Framework 4.8]
IDE and version : [e.g. Visual Studio 16.3]

Hi @Alilux.  I'm going to close this out as there are no details available for what you would like to discuss. If you're still in need of assistance, please feel free to open a new issue.

authors: Alilux jsquire


text:
[Servicebus] UserCallbackThrowingCausesMessageToBeAbandonedIfNotSettled("DeadletterOverload") failing in nightly runs

Servicebus nightly test runs are failing with:

Error message
Microsoft.Azure.Management.ServiceBus.Models.ErrorResponseException : Operation returned an invalid status code 'BadRequest'
Stack trace
at Microsoft.Azure.Management.ServiceBus.QueuesOperations.CreateOrUpdateWithHttpMessagesAsync(String resourceGroupName, String namespaceName, String queueName, SBQueue parameters, Dictionary2 customHeaders, CancellationToken cancellationToken)    at Microsoft.Azure.Management.ServiceBus.QueuesOperationsExtensions.CreateOrUpdateAsync(IQueuesOperations operations, String resourceGroupName, String namespaceName, String queueName, SBQueue parameters, CancellationToken cancellationToken)    at Polly.Retry.AsyncRetryEngine.ImplementationAsync[TResult](Func3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates1 shouldRetryResultPredicates, Func5 onRetryAsync, Int32 permittedRetryCount, IEnumerable1 sleepDurationsEnumerable, Func4 sleepDurationProvider, Boolean continueOnCapturedContext)
at Polly.AsyncPolicy1.ExecuteAsync(Func3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
at Azure.Messaging.ServiceBus.Tests.ServiceBusScope.CreateWithQueue(Boolean enablePartitioning, Boolean enableSession, Boolean forceQueueCreation, Nullable1 lockDuration, String overrideNamespace, String caller) in /Users/runner/work/1/s/sdk/servicebus/Azure.Messaging.ServiceBus/tests/Infrastructure/ServiceBusScope.cs:line 150    at Azure.Messaging.ServiceBus.Tests.Processor.ProcessorLiveTests.UserCallbackThrowingCausesMessageToBeAbandonedIfNotSettled(String settleMethod) in /Users/runner/work/1/s/sdk/servicebus/Azure.Messaging.ServiceBus/tests/Processor/ProcessorLiveTests.cs:line 605    at NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter1.BlockUntilCompleted()
at NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter awaiter)
at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func1 invoke)    at NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext context)    at NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext context)    at NUnit.Framework.Internal.Commands.TimeoutCommand.<>c__DisplayClass5_0.<RunTestOnSeparateThread>b__0()    at System.Threading.Tasks.Task1.InnerInvoke()
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
at NUnit.Framework.Internal.Commands.TimeoutCommand.Execute(TestExecutionContext context)

For more details check here:

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1051802&view=results

This is a transient failure with the ARM client and is not related to the SDK.

authors: JoshLove-msft v-yilinhu


text:
unexpected output from Get-AzRecoveryServicesVaultProperty

[trying to get the Azure recovery services vault storage setting from PowerShell is not working and gives an empty result
PS /home/zahraa> $vault = Get-AzRecoveryServicesVault -ResourceGroupName "zahraasaleh" -Name "zahraasaphana2"
PS /home/zahraa> $vaultProperty = Get-AzRecoveryServicesVaultProperty -VaultId $vault.Id
PS /home/zahraa> $vaultProperty

]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d8253173-a9b2-838a-9ade-5cd17efea3d2
Version Independent ID: 82019acf-744a-3892-985c-34170bf568c3
Content: BackupResourceVaultConfigResource Class (Microsoft.Azure.Management.RecoveryServices.Backup.Models) - Azure for .NET Developers
Content Source: xml/Microsoft.Azure.Management.RecoveryServices.Backup.Models/BackupResourceVaultConfigResource.xml
Service: site-recovery
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

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

@dingmeng-xue please help to check this issue

authors: ArthurMa1978 jsquire zahraasaleh


text:
[FEATURE REQ] DownloadToByteArray for partial load of header information of big file from storage

Library name
Azure.Storage.Blobs
Please describe the feature.
In the v11 there was this option to partially load data from storage with given length:
var maxHeaderBytes = Math.Min(blobProperties.ContentLength, QueueUtils.GetMaxFileSize(context));             byte[] originalBlobBytes = new byte[maxHeaderBytes];             await blob.DownloadRangeToByteArrayAsync(originalBlobBytes, 0, 0, maxHeaderBytes).ConfigureAwait(false);
What would be the equivalent to v12? Could not find any method which solves this. I don't want to download the whole (big) file to Azure Function to read out the header information.
I only found another request in that direction on another forum: https://quabr.com/59995185/download-only-the-first-few-bytes-of-an-azure-blob

hello @agravity-philipp We are routing this query to Service Team's Attention.

authors: SatishBoddu-MSFT agravity-philipp


text:
[BUG] x-ms-version header not supported by Blob Service

Library name and version
Azure.Storage.Blobs 12.14.1
Describe the bug
After updating from version 12.13.0 to 12.14.1, our calls to all blob containers in one resource group are failing. There are no problems when reverting to 12.13.0
The same package works correctly for other storage accounts in different resource groups.
Appears similar to this issue: #29098
Is it possible the latest Storage service version is not rolled out to all Storage Accounts in Azure?
Expected behavior
I would expect the call to not fail due to a package update.
Actual behavior
Error in FunctionApp:

Plain text error message (from AppService):
The value for one of the HTTP headers is not in the correct format.
RequestId: 6eab0834-301e-00de-2824-e592af000000
Time: 2022-10-21T08:08:11.5522799Z
Status: 400 (The value for one of the HTTP headers is not in the correct format.)
ErrorCode: InvalidHeaderValue
Additional Information:
HeaderName: x-ms-version
HeaderValue: 2021-10-04
InvalidHeaderValue
The value for one of the HTTP headers is not in the correct format.
RequestId: 6eab0834-301e-00de-2824-e592af000000
Time: 2022-10-21T08:08:11.5522799Z
x-ms-version 2021-10-04
Headers:
Server: Windows-Azure-Blob/1.0,Microsoft-HTTPAPI/2.0
x-ms-request-id: 6eab0834-301e-00de-2824-e592af000000
Date: Fri, 21 Oct 2022 08:08:10 GMT
Content-Length: 329
Content-Type: application/xml
Reproduction Steps
Sample code:
var blobContainerClient = new BlobContainerClient(settings.ConnectionString, settings.ContainerName, new BlobClientOptions());
await blobContainerClient.CreateIfNotExistsAsync();

Environment
.NET 6 AppService and Function App
IDE(s) Occurs when debugging in VS2022 and JetBrainsRider, and in the cloud environment

I had the same issue when running my project's tests  (which calls azurite) after trying to update from 12.12.0 to 12.14.1

For the original poster, looks like on the storage service side we need to check if that version hasn't reached that storage account / resource group. We are in contact with the service to make sure that this gets resolved soon.
As for those using Azurite, looks like this is has been an issue before where the SDK updated the service version before Azurite did.
As for both issues, a mitigation we recommend downgrading to 12.13.0 to prevent the InvalidHeaderValue error from popping up. I would recommend opening up an issue in Azurite as they need to eventually support this service version.
https://github.com/Azure/Azurite/issues
cc @blueww for Azurite.
Apologies for any inconvenience this may have caused.

@UnleashMayhem Could you please confirm if your storage account region is West Europe ? If Yes, I tried to re-create the same issue by using the x-ms-version: 2021-10-04 and it worked fine for Blob operations. Could you please confirm if you are still facing the same issue ? Awaiting your reply.

The issue has been resolved on the storage service side, please tag my github alias if we should unresolve.
As for the Azurite issue, we saw that they already support service version 2021-10-04 in the latest version of Azurite so please let us know if there's an issue with Azurite still.

@Etiennepicard
Azurite already support API version 2021-10-04 on 3.19.0 and later, about 2 months ago.
Please check the Azurite version, and upgrade it if necessary.
BTW, you can also start Azurite with --skipApiVersionCheck, so Azurite will fail since API version not support. See more details in https://github.com/Azure/azurite#skip-api-version-check

@UnleashMayhem, would it be possible for you to provide the storage account name?  We would like to verify that this issue has been fixed.

authors: Etiennepicard UnleashMayhem amnguye blueww navba-MSFT seanmcc-msft


text:
Items inside GetBeckupProtectedItems() collection cannot be parsed due to Error: 'Value cannot be an empty string. (Parameter 'resourceId')'

Library name and version
Azure.ResourceManager.RecoveryServicesBackup 1.2.0
Query/Question
Hi
I have the following snippet for my code:
//var backupProtectedItems = resourceGroupResource.GetBackupProtectedItemsAsync(request.VaultName, filter);
var backupProtectedItems = resourceGroupResource.GetBackupProtectedItems(request.VaultName);
foreach (var backupProtectedItem in backupProtectedItems) {  // error on this line
// do sth;
}
The vault only has Vm backup items. when the vault has an item with stepped backup state ("protectionState": "ProtectionStopped") or softdleted item, the code errors out on line where I have foreach with error:  'Value cannot be an empty string. (Parameter 'resourceId')', it cannot parse the item. I am not sure if this is the expected behaviour.
can you pls help me to resolve this issue. Thanks
Environment
net 8 isolated runtime, azure durable function on consumption plan

Hi, any update on this issue? thanks.


text:
[Search][BUG] Wrong dynamic for empty array of string

Having two fields declared as
new Field("tags", DataType.Collection(DataType.String)) {IsRetrievable=true, IsFilterable=true, IsSortable=false, IsFacetable=false, IsSearchable=true, Analyzer= AnalyzerName.EsMicrosoft },
new Field("tagsModelos", DataType.Collection(DataType.String)) {IsRetrievable=true, IsFilterable=true, IsSortable=false, IsFacetable=false, IsSearchable=true, Analyzer= AnalyzerName.EsMicrosoft },

And in Azure correctly created

The search result returs an array of string when the array has some elements and an empty array of object when the array is empty.

The bug was found in version 10.1.0 actualizing from 3.x so... I don't know which is the exact version where the bug was introduced.

The applied workaround is
// workaround BUG introduced by AzureSearch 10 package.
// The empty array of strings y returned as array of objects
// reported: https://github.com/Azure/azure-sdk-for-net/issues/8699
var t = ((source.tags as IEnumerable) ?? new object[0])
		.Cast<object>().Where(x=> x!=null).Select(x=> x.ToString()).ToArray();
var tm = ((source.tagsModelos as IEnumerable) ?? new object[0])
		.Cast<object>().Where(x=> x!=null).Select(x=> x.ToString()).ToArray();

This behavior is by design.
In the dynamic case, the SDK has no information about what data type is contained within the collection. In previous versions, the only collection type that was supported was Collection(Edm.String), but now that collections of arbitrary type are supported, there is no way to know what the correct type should be for an empty collection. It is less likely to violate the Principle of Least Surprise to use the most expansive type (object[]) rather than a type that could be incorrect (string[], which would be incorrect if the field is an integer collection, for example).
If your application is aware of the types of these fields, then I'd recommend using your own model type as this will guide deserialization and always result in the correct .NET type (assuming you've defined your model type correctly).
We do not plan to change this behavior, especially since there is a workaround, so I'm closing this issue.

"by design", really?
I'm curious to see the tests where you are checking the "design".
Inside those tests you should define an index with an array of strings, then you should store an empty array of string and, in the assert, you should check that the response of the document contains an empty array of objects (object[]).
Why you are constraining a user to define a type of a collection to then check the type when the user store something but, in the response, you are returning an aubergine?
In OSS "by design" is not a magic word to avoid bug fix.
BTW make what your professionalism say you.
Be the force with you!

@fabiomaulo My apologies, I should not have closed the issue without further discussion. I've re-opened it until we can reach a consensus.

I'm curious to see the tests where you are checking the "design".

The test for this case is here: https://github.com/Azure/azure-sdk-for-net/blob/0ad10546a38696c52c070bfc94e3c2d7d613efcd/sdk/search/Microsoft.Azure.Search/tests/Tests/Serialization/DocumentConverterTests.cs#L363
There are other tests in the same file that pin other behaviors that similarly aren't ideal and are caused by the lack of type information.
This behavior is documented here.

Why you are constraining a user to define a type of a collection to then check the type when the user store something but, in the response, you are returning an aubergine?

I will explain in more detail why this doesn't work the way you expect. I will also list the alternatives we considered.
In the .NET SDK, there are two sets of data retrieval methods: Those that take a generic type parameter, and those that don't. Both sets of methods use JSON.NET to deserialize the JSON responses returned by Azure Cognitive Search. In the case of the generically-typed methods, the type you pass is supposed to correspond to your index definition, and it's used to deserialize each JSON property in the response to its correct type. However, for the methods that don't take a type parameter, there is no type information available to determine the actual type of the data in the response. This is because the REST API does not return fully self-describing responses. For this reason, the implementation currently has to make some assumptions. For empty collections, the assumption is that it's less surprising to receive object[] for say, Collection(Edm.Int32), than it is to receive string[] in that case.
This is not ideal behavior, so we considered some ways to fix it:

Change the REST API to include type information that would disambiguate situations like this. This is an expensive change for us to make, and to date this hasn't been a priority for our customers, so we've focused on other work to improve the service instead.
Use Index instances on the client-side to get type information for deserialization. This could be done either by requiring the Index as a parameter, which would be inconvenient, or by transparently fetching and caching index definitions on the client, which has a few problems:

Performance: On cache misses, it could greatly increase latency. Generally it's a design goal of the Azure SDKs to have predictable performance, and not hide multiple calls to the REST API within a single method unless there's a very compelling reason.
Consistency: It's possible the index definition will change (for example, if the index is deleted and recreated between queries, something a surprising number of our customers do periodically), making the client type information incorrect anyway. It's hard to detect this case without expensive polling.

So while it's possible to fix this, none of the fixes are easy and they all have their own drawbacks. Also, workarounds are possible.
If you have an idea for fixing this that is simpler and more robust than what I've mentioned, we would be happy to consider it.

Hi Bruce.
The force with you is.
Thanks for the feedback.
The problem here is something I saw even in others SDKs (IIRC docDb) and, IMO, is a conceptual error: don't touch the dynamic result ;).
You give us a way to work with strongly-typed DTO/entities and with dynamic-objects;
when we use the dynamic object (and here I should explain to you the reason but it is for a call) you should avoid obscuring the real nature of the underlining object returned by the API. This mean that you should return the result o the JSON.NET deserialization or a transformation of the deserialization maintaining just a part of the JSON.NET result. You shouldn't try to transform it into another object.
In the Search-SDK case, you shouldn't return a DocumentSearchResult<Document>, instead you should return a DocumentSearchResult<dynamic>. This way you are giving us a way to understand what the underlying object is and so a way to work with its power.
Receiving a real dynamic I can see that it is a JSON.NET and I can deal with it:
class MyArrays
{
	public int[] Int { get; set; } = null;
	public DateTime[] Dates { get; set; } = new DateTime[0];
	public string[] Strings { get; set; } = new string[0];
}
static void Main(string[] args)
{
	var sedialized = Newtonsoft.Json.JsonConvert.SerializeObject(new MyArrays());
	dynamic deserialized = Newtonsoft.Json.JsonConvert.DeserializeObject(sedialized);
	var mypropAsStrings = deserialized.Dates.ToObject<string[]>();
	var mypropAsInt = deserialized.Strings.ToObject<int[]>();
	var mynullarray = deserialized.Int?.ToObject<int[]>();
	Console.WriteLine($"{mypropAsStrings.GetType()} {mypropAsStrings.Length}");
	Console.WriteLine($"{mypropAsInt.GetType()} {mypropAsInt.Length}");
	Console.WriteLine($"{mynullarray?.GetType()} {mynullarray?.Length}");
	Console.ReadLine();
}

In practice: don't try to transform the dynamic to a Dictionary<string, object> when what a need/want is dynamic. Give us the dynamic you have in your hands and that is all ;) .
I'll happy to read your opinion about DocumentSearchResult<dynamic> and/or to talk with you if you need some explication about the reason I'm using a dynamic instead a strongly-typed DTO to read/write the index.
P.D. just something to transform the dynamic without know what it contains: https://gist.github.com/fabiomaulo/d03700a8ea1ec99d8725058cc67b10a7

@fabiomaulo Thanks for the explanation -- this makes sense now. The fact that you can convert an empty JArray to any type you want seems to be the missing piece for your scenario.
This feedback comes at a good time, because we're starting to think about the next generation of the .NET SDK. Several months ago, new Azure API Guidelines were announced, and we plan to re-engineer our .NET SDK to be compliant with these guidelines (although there is no timeline for this yet).
One complicating factor is that JSON.NET is being deprecated in favor of the new System.Text.Json library. So far it looks very low-level in comparison; it remains to be seen whether it will move toward feature parity with JSON.NET.
In the meantime, I'll keep this issue open to track this scenario and I'll run it by the Azure API review board. Please don't expect any short-term updates though -- this is very much a long-term issue.

Thanks.
I really appreciate your attitude: the real point behind an issue is to recognize and fix the problem and not close the ticket.

For Azure.Search.Documents, we're keeping everything as object[] until you ask for it as another type of array.  It's the same as keeping "NaN" a string until you ask for it as a double.  Once we have proper dynamic support in Azure.Core.Experimental, you should be able to cast to whatever you want and it'll "just work."  Moving this to the backlog for now and we'll close it out once we've got the end-to-end story in place.

We have support for this now. @Mohit-Chakraborty let's try and get a small sample written for this.

We have an example of extracting properties by name and casting them to a custom type here.

Closing this issue. Please let us know if you need further assistance or want to continue the discussion.

@Mohit-Chakraborty thanks I'll try it hopefully soon. We are in the process of converting all our prjs from net472+net22+net31 -> NET6 (obviously the problem are public-webs prjs).

Since the SearchDocument has methods such as GetBoolean, GetBooleanCollection, ad so on I have, at least, a way to ask for correct conversion.
You can close the issue.

authors: AlexGhiondea Mohit-Chakraborty brjohnstmsft fabiomaulo tg-msft


text:
Azure Key Vault package version updates.

Fix additional stale version references between packages.

Hi @herveyw, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (herveyw). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

authors: azurecla herveyw


text:
Azure Monitor Exporter - In debug mode write EventSource and Telemetry information to output window

Fixes #16893
Samples from Debug Output Window
OpenTelemetry-TraceExporter-AzureMonitor - EventId: [2], EventName: [WriteError], Message: [FailedToSend - Azure.RequestFailedException: No such host is known ---> System.Net.Http.HttpRequestException: No such host is known ---> System.Net.Sockets.SocketException: No such host is known
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask`1 creationTask)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at Azure.Core.Pipeline.HttpClientTransport.ProcessAsync(HttpMessage message)
   --- End of inner exception stack trace ---
   at Azure.Core.Pipeline.HttpClientTransport.ProcessAsync(HttpMessage message)
   at Azure.Core.Pipeline.RequestActivityPolicy.ProcessNextAsync(HttpMessage message, ReadOnlyMemory`1 pipeline, Boolean isAsync)
   at Azure.Core.Pipeline.RequestActivityPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline, Boolean isAsync)
   at Azure.Core.Pipeline.ResponseBodyPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline, Boolean async)
   at Azure.Core.Pipeline.ResponseBodyPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline)
   at Azure.Core.Pipeline.LoggingPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline, Boolean async)
   at Azure.Core.Pipeline.LoggingPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline)
   at Azure.Core.Pipeline.RetryPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline, Boolean async)
   at Azure.Core.Pipeline.RetryPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline, Boolean async)
   at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline)
   at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline)
   at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline)
   at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory`1 pipeline)
   at Microsoft.OpenTelemetry.Exporter.AzureMonitor.ApplicationInsightsRestClient.InternalTrackAsync(IEnumerable`1 body, CancellationToken cancellationToken)

{"name":"RemoteDependency","time":"11/11/2020 22:04:19","iKey":"Ikey","tags":{"ai.cloud.role":"my-namespace.my-service","ai.cloud.roleInstance":"roleinstance1","ai.operation.id":"3e8db816d2c04348a0d878cc4aef3b1c","ai.internal.sdkVersion":"dotnet4.6:otel0.7.0:ext1.0.0"},"data":{"baseType":"RemoteDependencyData","baseData":{"id":"fe14831888574b4d","name":"POST:/api/request","resultCode":"200","data":"http://localhost:19999/api/request/","type":"HTTP","duration":"00:00:00.0013742","success":true,"properties":{"response.content":"echo: client message: 11/11/2020 2:04:19 PM","response.length":"43","http.header.Server":"Microsoft-HTTPAPI/2.0","http.header.Date":"Wed, 11 Nov 2020 22:04:19 GMT"},"ver":2}}}
{"name":"Request","time":"11/11/2020 22:04:20","iKey":"Ikey","tags":{"ai.cloud.role":"my-namespace.my-service","ai.cloud.roleInstance":"roleinstance1","ai.operation.id":"f999ca2e87d2eb4287ff3d3cdb7ba371","ai.internal.sdkVersion":"dotnet4.6:otel0.7.0:ext1.0.0"},"data":{"baseType":"RequestData","baseData":{"id":"55fe4f0b76b4d84c","name":"POST:/api/request/","duration":"00:00:00.0005569","success":true,"responseCode":"200","url":"http://localhost:19999/api/request/","properties":{"http.header.Content-Length":"37","http.header.Content-Type":"text/plain; charset=utf-8","http.header.Host":"localhost:19999","request.content":"client message: 11/11/2020 2:04:20 PM","request.length":"37"},"ver":2}}}

LGTM

authors: TimothyMothra rajkumar-rangaraj


text:
Drop 'batch' from healthcare samples

solves #21231

@maririos


text:
CheckIpAddressAvailability API + ResourceNavigationLinks on subnets

SDK changes for CheckIpAddressAvailability API on Virtual Networks

Can one of the admins verify this patch?

Hi @AhmedSalama-MS, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (ahsalam). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

LGTM @amarzavery

@azuresdkci add to whitelist

@AhmedSalama-MS Please respond to review comments

authors: AhmedSalama-MS DeepakRajendranMsft azurecla azuresdkci markcowl


text:
DRAFT [LLC] Implement RequestOptions.AddPolicy

Provide AddPolicy method on RequestOptions (RequestContext for now) with the same API as AddPolicy on ClientOptions.
To include the policies added by RequestOptions, we create a new ReadOnlyMemory to hold all policies (client and request) when a protocol method with request policies is called. We use ArrayPool to pool the memory so we avoid allocations.
Fixes: https://github.com/azure/azure-sdk-for-net/issues/24907

API changes have been detected in Azure.Core. You can review API changes here
API changes
+         public void AddPolicy(HttpPipelinePolicy policy, HttpPipelinePosition position);
+         public HttpMessage CreateMessage(RequestContext context);

API changes have been detected in Azure.Core. You can review API changes here
API changes
+         public void AddPolicy(HttpPipelinePolicy policy, HttpPipelinePosition position);
+         public HttpMessage CreateMessage(RequestContext context);

Can you add a line to changelog please?

authors: annelo-msft azure-sdk pakrym


text:
[AzureMonitorExporter] refactor, prepping for LiveMetrics proj

I intend to import the ConnectionString Parsing and Platform Abstractions into the LiveMetrics project.
These classes have some EventSource logging that needs to be refactored.
The end goal is to have same EventSource methods in both projects. For example:
#if AZURE_MONITOR_EXPORTER
    AzureMonitorExporterEventSource.Log.FailedToParseConnectionString(ex);
#elif LIVE_METRICS_EXPORTER
    LiveMetricsExporterEventSource.Log.FailedToParseConnectionString(ex);
#endif

Changes

Add constant Azure_Monitor_Exporter to the Azure.Monitor.OpenTelemetry.Exporter project.
Edit the ConnectionStringParser to wrap the EventSource call.
Edit DefaultParser

The initialization exception will be wrapped.
The CreateDirectory exception is specific to AzureMonitor. I pulled this try/catch out of the DefaultPlatform and into the StorageHelper instead.

Minor refactor IPlatform and update unit tests.

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

authors: TimothyMothra azure-sdk


text:
Update Azure Database Migration Service to add Managed Instance as target

Swagger spec - https://github.com/Azure/azure-rest-api-specs/tree/master/specification/datamigration/resource-manager/Microsoft.DataMigration/preview/2018-03-15-preview
PR link - https://github.com/Azure/azure-rest-api-specs/pull/2531
Description

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] Please add REST spec PR link to the SDK PR
[x] I have read the contribution guidelines.
[x] The pull request does not introduce breaking changes.

General Guidelines

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

SDK Generation Guidelines

[x] 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] 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.
[x] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK.

@dsgouda , I tried running:
msbuild build.proj /t:build /p:Scope=Sdks/DataMigration.
The build succeeded but it did not generate .props file.

Hmm it should, can you try this instead
Please make sure you have run
msbuild build.proj

this installs all the tools required for building this repo
 msbuild build.proj /t:build /p:Scope=SDKs/DataMigration

@dsgouda That worked. Added the props file.

Please let me know if anything else is needed from my side to get this merged and published.
Scope - SDKs\DataMigration
Package Name - Microsoft.Azure.Management.DataMigration

@shahabhijeet PTAL and merge

authors: dsgouda hitenjava


text:
Convert number lookup ga to preview

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

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


text:
Update autorest version to prerelease 3.0.0-alpha.20240522.7

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

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


text:
Automatic PR of restapi_auto_azhao155_Network-20180101 into master

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

Will handle Network manually

authors: AutorestCI lmazuel

repo: Azure/azure-sdk-for-python


text:
[EventHub] drop python 2.7/3.6

fixes: #22267

/azp run python - eventhub - tests

/azp run python - eventhub - ci

/azp run python - eventhub - ci

/azp run python - eventhub - tests


text:
[SchemaRegistry] add support for getting schema by version

Service already supports getting schema by version and this operation has been added to the swagger. This PR regenerates from that swagger and adds support for this feature. Specifically:

Adding the get_schema_by_version methods on the sync and async clients.
Adding version ivar to the SchemaProperties model.

TODO:

[x] add tests
[x] update README, samples README, and changelog

addressing: #25072

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

/azp run python - schemaregistry - tests

authors: azure-sdk swathipil


text:
Increment version for monitor releases

Increment package version after release of azure-monitor-query

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


text:
[AutoPR frontdoor/resource-manager] Update regex for Front Door name

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

(message created by the CI based on PR content)

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


text:
[AutoRelease] t2-appcontainers-2024-03-06-14952(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/5027
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=4772

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


text:
Az Config Python for both sync and async

Both sync and async code work.
Replayable unit tests of both sync and async have passed.
Based on msrest. Will migrate to Azure core next step.
Still have lock/unlock in the code. Will remove them after migrating to Azure core.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Close this request as it's trying to merge to central repo master and we're not ready to merge there.
Instead another pull request is created to merge to branch appconfig of central repo.
https://github.com/Azure/azure-sdk-for-python/pull/5045


text:
[AutoPR] maintenance/resource-manager

Created to accumulate context: maintenance/resource-manager

(message created by the CI based on PR content)

/azp run

authors: AutorestCI zikalino


text:
APIview misc fixes

Python team and architects have asked for change to allow closing reviews by anyone. Currently only owner is allowed to close the reviews and this causes some stale reviews to be present in system. This change is to make it similar to github where other developers are allowed to close a PR.
Second change in this PR is to show upvote button in comments as active if at least one has upvoted it.

For upvotes I think the right thing is:

Person that upvoted - active button, not grey
Others - not active button, not grey

authors: pakrym praveenkuttappan

repo: Azure/azure-sdk-tools


text:
[ASP.NET SignalR]Add a sample project for old signalr

This sample includes

a simple one following https://docs.microsoft.com/en-us/aspnet/signalr/overview/getting-started/tutorial-getting-started-with-signalr, and a simple authorization
and a comparatively complex one as similar to https://github.com/aspnet/AzureSignalR-samples/tree/master/samples/AdvancedChatRoom, covering all the user scenarios, and a cookie based authentication.

This sample is to get ready for switching to Azure 😄

Can dotnet CLI build such hybrid solution?

authors: vicancy xscript

repo: Azure/azure-signalr


text:
Adding Queue output binding with custom SAS connection string resulted in error

I've added today queue output to an existing function. This is my function.json:
{
  "bindings": [
    {
      "name": "myTimer",
      "type": "timerTrigger",
      "direction": "in",
      "schedule": "0 0 * * * *"
    },
    {
      "type": "queue",
      "name": "collector",
      "queueName": "<my-queue-name>",
      "connection": "AnalticsQueueSAS",
      "direction": "out"
    }
  ],
  "disabled": false
}

At first, I created a configuration with the name AnalticsQueueSAS in the application settings, as app settings and not a connection string. This resulted in error, which mention the name of the setting should be AzureWebJobsAnalticsQueueSAS. After changing the setting name, now I have a new error:
Function ($TimerTriggerCSharp1) Error: Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.TimerTriggerCSharp1'. Microsoft.Azure.WebJobs.Host: No blob endpoint configured.
Session Id: 26bb9ad175eb4d8780f54b9054085793

Timestamp: 2017-07-12T08:28:54.926Z

This is the connection string I am using (and I've set it in the application settings):
QueueEndpoint=https://<my_account>.queue.core.windows.net;SharedAccessSignature=sv=<my-SAS>

The queue is in classic storage, and not ARM storage - but I could not find any documentation if this is an issue. Also, as you can see, I don't have anything that is Blob related - so I am not really sure why there is an error.
Thanks,
Omer

Do you have your AzureWebJobsStorage setting set correctly? Timer relies on Blob Storage to manage the leases.

I now removed the queue binding, and look like everything is working correctly, so it is probably not that...

where did you find references on how to use SAS connection strings with function output bindings? I want to use a blob output binding but I can't get it working.

I think I've just tried and it looks like it works... Never had the chance to actually make sure something is written to the blob...

authors: christopheranderson omerlh sebbsan

repo: Azure/azure-webjobs-sdk-script


text:
Provide an auto-fix for compiler error of "Location does not exist"

When a user is creating a snippet, if they haven't created a parameter named location previously, I think it would be great to provide them an autofix to give them
"param location string" at the top of their file in just one click.

I agree.  Another possibility is to have snippets automatically handle this.

We need to figure this out or consider disabling the rule by default.

authors: StephenWeatherford ucheNkadiCode

repo: Azure/bicep


text:
Update sample Jupyter notebooks to reflect the Python library version

Please provide us with the following information:

Problem
The current sample Jupyter notebooks in this project were created before the project transitioned to a Python library. As a result, the existing notebooks do not reflect the new API usage for the Python library version of the project.
Solution
Create updated sample Jupyter notebooks that demonstrate how to use the Python library for translation tasks. These updated notebooks should showcase:

How to set up and initialize the library
How to translate markdown files and images using the new Python library
How to configure language codes, file paths, and translation options using the library
Best practices for integrating the library into other projects

This update will ensure that the examples align with the current version of the project and provide users with accurate and helpful documentation for using the Python library.
Action Items

Replace the old sample notebooks with updated ones that use the Python library.
Ensure all notebooks are tested with the latest version of the library.

This issue is for a: (mark with an x)
- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Any log messages given by the failure

Expected/desired behavior

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

azd version?

run azd version and copy paste here.

Versions

Mention any other details that might be useful

Thanks! We'll be in touch soon.

We have decided to close this issue.
Since Co-op Translator is CLI-based, we believe it's more effective to provide various CLI usage examples through markdown documentation rather than implementing them in a notebook. During the POC (Proof of Concept) phase, notebooks were important for demonstrating concepts. However, now that we've transitioned to an open-source project, we've decided to remove the notebooks. Instead, we'll offer detailed guides and various examples in markdown format.
Therefore, we are closing this issue.

repo: Azure/co-op-translator


text:
[Doc] Add FAQ for integration on the lower minimum deployment target

Purpose

Add FAQ for integration on the lower minimum deployment target

Does this introduce a breaking change?

[ ] Yes
[x] 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)
[x] Documentation content changes
[ ] Other... Please describe:

Looks good, just some minor suggestions on the wording.

Thanks for rewording!

repo: Azure/communication-ui-library-ios


text:
This is more a question then a issues

Can I use this framework to talk to the sensor, in case the sensor is more then just a temperature reader my can open relay?

At this point you cannot do this with these samples which are mainly focused on telemetry data sent from devices up to Azure.
We are working on adding this capability to the samples and you should start seeing some of these in a couple weeks from now.
In the meantime, you can look into options such as Azure Mobile services, Azure Notification Hubs or event Service Bus Topics.
Stay tuned

I am making good progress on the Azure IoT Hub support (see the IoTHub branch) which is bringing the ability to send messages back to devices from Azure through Azure IoT Hub. I'll label this issue as a feature request and will close once the V2 is pushed into Master (should be real soon!)

IoTHub support is now full there. I have added a Cloud to Device Message from the backend down to the devices each time there is an alert triggered. You can check how it's don't in the latest website code. I will update the devices code as well, for now only the NodeJS desktop sample does something out of the incoming message.

authors: bmorneau olivierbloch

repo: Azure/connectthedots

license: mit

license_source: bigquery


text:
More source unit tests

After #110 we have unit tests covering a fairly large number of cases for source configurations, but its missing some things:

The docker image source with cmd supports mounting another source spec in.
The Build source only tests inline dockerfiles
i. We can even drop the inline field after #98
ii. Probably we have this test too tightly coupled with the actual dockerfile format (its using dockerfile2llb to convert a literal dockerfile to llb). Even though the source type is for building a dockerfile, that implementation is outside the scope of what we are testing and we can probably just stub out the implementation and make sure that the correct function to forward the request to buildkit is being called.

I am going to add basic unit tests for source spec mounting for docker image with cmd in #117

repo: Azure/dalec


text:
De-duped and fixed types

Removed types package/src/types.ts that already exist in package/src
Added a 3rd Worker type "AugmentedWorker" and made it more clear that the public worker type and the actual worker interface are different (still not that clear, but at least it's a little better?)
Fixed mistakes in types

Added a 3rd Worker type "AugmentedWorker" and made it more clear that the public worker type and the actual worker interface are different (still not that clear, but at least it's a little better?)

I think it helps at least draw some sort of line that they are different even if it's just creating a new AugmentedWorker type. I think it's a good idea to use your new change.

authors: Weffe maxburs

repo: Azure/monaco-kusto


text:
CSS part of Vue app is not rendered on dev server

Describe the bug
The <style> part of  SFC(Single File Component) is not rendered when launching Vue App using SWA CLI via dev server.
To Reproduce
Steps to reproduce the behavior:

Create a new Vue app with npm init vite@latest my-vue-app --template vue
cd my-vue-app && npm i
Type in command swa start http://localhost:3000 --run "npm run dev"
Click on http://localhost:4280
Displaying HTML that does not reflect CSS written in <style> of App.vue (e.g. not centered)

Expected behavior
The HTML with CSS is displayed as if it was started on the native dev server.
Screenshots
Start with SWA CLI (http://localhost:4280')

Start with Vite dev server (http://localhost:3000)

Desktop (please complete the following information):

OS: Windows 11
Browser Chrome
Version [95.0.4638.69]

Additional context
If run it from static files after build, like swa start dist, it will be rendered correctly.

Hey @k-miyake can you please share a screenshot of the network/console tabs from the browser's devtool?

@manekinekko Here is a screenshot of the network/console tabs.

Looks like this issue is caused by #346

I'm also experiencing this issue using Vite and SvelteKit. Due to another issue described here, I had to temporarily downgrade to 0.8.0 to get to this point. I thought I'd bring it up because it sounds very similar to what's happening here.
I created a repo to recreate the issue: https://github.com/LHousehold/example-issue-azure-swa-sveltekit
The repo's readme describes the issue, but basically it seems like the file with the relevant CSS is not being loaded because Vite uses query params which route to different content.
http://localhost:3000/src/routes/index.svelte?svelte&type=style&lang.css
When accessed directly and working correctly, the above returns different content than the below, as if they are completely different files.
http://localhost:3000/src/routes/index.svelte
But when using the cli with port 4280, these two paths both return only the content from /index.svelte without the query params. I suspect k-miyake is facing a similar issue.

I think the issue @LHousehold reported with SvelteKit is the same issue I'm having, which is caused by Vite's dev server not reading the CSS correctly when started on port 4280 of the SWA CLI.

@manekinekko I have confirmed that this has been fixed in SWA CLI 0.8.2. Thank you for your support.

I'm having the same problem as @k-miyake with version 0.8.3 when using Vite and Vue.

We have fixed this issue in the next release. Will schedule a release soon.

authors: LHousehold SteveVaneeckhout k-miyake manekinekko

repo: Azure/static-web-apps-cli


text:
SWA is only deploying to a staging environment, even after merging PR

I have a SWA with a custom domain. When I visit the custom domain URL I get Your Azure Static Web App is live and waiting for your content and when I view the SWA in the portal, it tells me the status is waiting for deployment and also shows Prepare for production (2/3 completed).
In my Actions pipeline the only difference to the ootb template is that I'm building my nuxt3 app myself and so I set skip_app_build: true and skip_api_build.
When I raise a PR I see the bot message with the staging env url. And the link works and shows my nuxt site. When I merge the PR, the close job runs which uses action: close and secondly, the build job runs again. After the build job is completed I get a notification email again that my staging env is ready.
So what am I missing? How do I switch staging into production?

Here's my pipeline
name: "Deploy node-votes-2 App"

on:
  workflow_dispatch:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    paths:
      - "apps/node-votes-2/apps/node-votes-app/**"

permissions:
  id-token: write
  contents: read
  pull-requests: write

env:
  AZURE_SUBSCRIPTION: zzz
  APP_RESOURCE_GROUP: zzz
  STATIC_WEB_APP_NAME: zzz

jobs:
  deploy:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy App
    steps:
      - uses: actions/checkout@v3

      - name: Azure login
        uses: Azure/login@v1
        with:
          creds: ${{ secrets.SP_ITOPS_MCS }}

      - name: Get SWA deployment key
        id: get_deployment_key
        uses: azure/CLI@v1
        with:
          azcliversion: 2.54.0
          inlineScript: |
            APIKEY=$(az staticwebapp secrets list --name ${{ env.STATIC_WEB_APP_NAME }} --resource-group ${{ env.APP_RESOURCE_GROUP }} --subscription ${{ env.AZURE_SUBSCRIPTION }} | jq '.properties.apiKey' -r)
            echo "::add-mask::$APIKEY"
            echo "apikey=$APIKEY" >> $GITHUB_OUTPUT

      - name: Setup nodejs
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"

      - name: Cache node_modules
        id: cache-node-modules
        uses: actions/cache@v3
        with:
          path: "**/node_modules"
          key: ${{ runner.os }}-node-modules-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-node-modules-

      - name: Install yarn
        run: npm install -g yarn

      - name: Build
        working-directory: ./apps/node-votes-2/apps/node-votes-app
        run: |
          yarn install --frozen-lockfile
          yarn build
          cp staticwebapp.config.json .output/public/staticwebapp.config.json

      - name: Build And Deploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ steps.get_deployment_key.outputs.apikey }}
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          action: "upload"
          skip_app_build: true
          app_location: ./apps/node-votes-2/apps/node-votes-app/.output/public
          skip_api_build: true
          api_location: ./apps/node-votes-2/apps/node-votes-app/.output/server
          output_location: ""

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Azure login
        uses: Azure/login@v1
        with:
          creds: ${{ secrets.SP_ITOPS_MCS }}

      - name: Get SWA deployment key
        id: get_deployment_key
        uses: azure/CLI@v1
        with:
          azcliversion: 2.54.0
          inlineScript: |
            APIKEY=$(az staticwebapp secrets list --name ${{ env.STATIC_WEB_APP_NAME }} --resource-group ${{ env.APP_RESOURCE_GROUP }} --subscription ${{ env.AZURE_SUBSCRIPTION }} | jq '.properties.apiKey' -r)
            echo "::add-mask::$APIKEY"
            echo "apikey=$APIKEY" >> $GITHUB_OUTPUT

      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ steps.get_deployment_key.outputs.apikey }}
          action: "close"
          app_location: ""

FWIW I got it working by swapping out the Azure/static-web-apps-deploy action with the SWA CLI.
Add SWA CLI dev dependency: yarn add @azure/static-web-apps-cli --dev
Update package.json
  "scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev",
    "generate": "nuxt generate",
    "preview": "nuxt preview",
    "postinstall": "nuxt prepare",
    "swa": "swa"
  },

Then in my pipeline I can deploy to production with:
yarn swa deploy ./apps/node-votes-2/apps/node-votes-app/.output/public \
  --api-location ./apps/node-votes-2/apps/node-votes-app/.output/server \
  --deployment-token ${{ steps.get_deployment_key.outputs.apikey }} \
  --env production

Updated & simplified pipeline using SWA CLI. Note that PR > staging is not required as this is for POC and in any case, we use different subscriptions for dev / stage / prod so temporary environments is not needed.
name: "Deploy node-votes-2 App"

on:
  workflow_dispatch:

permissions:
  id-token: write
  contents: read
  pull-requests: write

env:
  AZURE_SUBSCRIPTION: zzz
  APP_RESOURCE_GROUP: zzz
  STATIC_WEB_APP_NAME: zzz
  NODE_VERSION: 18

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Build and Deploy App
    steps:
      - uses: actions/checkout@v3

      - name: Azure login
        uses: Azure/login@v1
        with:
          creds: ${{ secrets.SP_ITOPS_MCS }}

      - name: Get SWA deployment key
        id: get_deployment_key
        uses: azure/CLI@v1
        with:
          azcliversion: 2.54.0
          inlineScript: |
            APIKEY=$(az staticwebapp secrets list --name ${{ env.STATIC_WEB_APP_NAME }} --resource-group ${{ env.APP_RESOURCE_GROUP }} --subscription ${{ env.AZURE_SUBSCRIPTION }} | jq '.properties.apiKey' -r)
            echo "::add-mask::$APIKEY"
            echo "apikey=$APIKEY" >> $GITHUB_OUTPUT

      - name: Setup nodejs
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"

      - name: Cache node_modules
        id: cache-node-modules
        uses: actions/cache@v3
        with:
          path: "**/node_modules"
          key: ${{ runner.os }}-node-modules-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-node-modules-

      - name: Install yarn
        run: npm install -g yarn

      - name: Build
        working-directory: ./apps/node-votes-2/apps/node-votes-app
        run: |
          yarn install --frozen-lockfile
          yarn build
          cp staticwebapp.config.json .output/public/staticwebapp.config.json

      - name: Deploy
        working-directory: ./apps/node-votes-2/apps/node-votes-app
        run: |
          yarn swa deploy .output/public \
            --api-location .output/server \
            --api-version ${{ env.NODE_VERSION }} \
            --deployment-token ${{ steps.get_deployment_key.outputs.apikey }} \
            --env production

This is just madness. The above is in fact not working. The only way to deploy to prod is to manually type the SWA CLI command as per the above. When running locally, it always deploys to the prod endpoint - the one linked to the custom domain. When the exact same CLI command is run in CI, it reverts back to deploying to a staging environment.
What is the logic behind all of this? Is there a way of disabling these 'smarts'?
Also I've explicitly disabled staging environments. My Bicep file:
resource staticWebApp 'Microsoft.Web/staticSites@2022-09-01' = {
  name: appResourceNames.staticWebApp
  location: location
  sku: {
    name: 'Standard'
    tier: 'Standard'
  }
  properties: {
    stagingEnvironmentPolicy: 'Disabled'
    allowConfigFileUpdates: true
    provider: 'None'
  }
  tags: tags
}

Apologies but I think a typo in my pipeline script resulted in deploying to a different SWA resource. So what appeared to be a staging env was in fact the prod env of a different SWA.
At least I have another method for SWA deployments though.

repo: Azure/static-web-apps


text:
chore: repository governance

Repository governance update
This PR was automatically created by the AVM Team hive-mind using the grept governance tool.
We have detected that some files need updating to meet the AVM governance standards.
Please review and merge with alacrity.
Grept config source: git::https://github.com/Azure/Azure-Verified-Modules-Grept.git//terraform
Thanks! The AVM team :heart:

Supersceeded by #60


text:
Error: reading Policy Set Definition "1f3afdf9-d0c9-4c3d-847f-89da613e70a8"

Hi,
No custom inputs but erroring on a particular initiative:
"Enable Monitoring in Azure Security Center"
"/providers/Microsoft.Authorization/policySetDefinitions/1f3afdf9-d0c9-4c3d-847f-89da613e70a8"

Thanks
Dan

Really sorry, opened incorrectly, provider version fixed at. 2.29. Changed to ~>2.40.0 and all good.

Really sorry, opened incorrectly, provider version fixed at. 2.29. Changed to ~>2.40.0 and all good.


text:
pushing for merge with the official repo

Hello everyone, Im creating this PR in order to merge the module I created during the Terraform Bug Bash!
Best regards!

@grayzu could you help @Guilhermeslucas to get this merged, please?

authors: Guilhermeslucas jcorioland

repo: Azure/terraform-azurerm-mariadb


text:
fix error:all list elements must have the same type

Ref to issue: https://github.com/Azure/terraform-azurerm-network-security-group/issues/32
Readme example error with terraform version 0.12.0

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


text:
Bug: Provider crash when modifying policy assignments

It looks like attempting to modify policy assignments at the second level causes a crash, e.g.:
policy_assignments_to_modify = {
    corp = {
      policy_assignments = {
        Deny-Public-IP-On-NIC = {
          enforcement_mode = "DoNotEnforce"
        }
      }
    }
  }

Results in:
module.alz.module.alz_global.data.alz_architecture.this: Still reading... [50s elapsed]

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Plugin did not respond
│
│ The plugin encountered an error, and failed to respond to the plugin6.(*GRPCProvider).ReadDataSource call. The plugin logs may contain more details.
╵

Stack trace from the terraform-provider-alz_v0.15.2.exe plugin:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x68 pc=0x1394ac5]

goroutine 171 [running]:
github.com/Azure/alzlib/deployment.(*HierarchyManagementGroup).ModifyPolicyAssignment(0x0, {0xc0005d3a28, 0x15}, 0x0, 0xc0010d63f0, {0x0, 0x0, 0x0}, 0x0, {0x0, ...}, ...)
        github.com/Azure/alzlib@v0.21.7/deployment/managementgroup.go:353 +0x65
github.com/Azure/terraform-provider-alz/internal/provider.modifyPolicyAssignments({_, _}, _, {{0x0, {0x0, 0x0}}, {0x2, {0xc00061d7c0, 0xb}}, {{0x0, ...}, ...}, ...}, ...)
        github.com/Azure/terraform-provider-alz/internal/provider/architecture_data_source.go:178 +0x82b
github.com/Azure/terraform-provider-alz/internal/provider.(*architectureDataSource).Read(0xc0009a2f88, {0x1ba4508, 0xc0007bc750}, {{{{0x1bab390, 0xc000b39bf0}, {0x18aac00, 0xc000ab3440}}, {0x1bae340, 0xc00063f180}}, {{{0x0, ...}, ...}, ...}, ...}, ...)
        github.com/Azure/terraform-provider-alz/internal/provider/architecture_data_source.go:108 +0x7f8
github.com/hashicorp/terraform-plugin-framework/internal/fwserver.(*Server).ReadDataSource(0xc00021a1e0, {0x1ba4508, 0xc0007bc750}, 0xc0006b5280, 0xc000b336d8)
        github.com/hashicorp/terraform-plugin-framework@v1.11.0/internal/fwserver/server_readdatasource.go:103 +0x751
github.com/hashicorp/terraform-plugin-framework/internal/proto6server.(*Server).ReadDataSource(0xc00021a1e0, {0x1ba4508?, 0xc0007bc660?}, 0xc0007bc600)
        github.com/hashicorp/terraform-plugin-framework@v1.11.0/internal/proto6server/server_readdatasource.go:55 +0x389
github.com/hashicorp/terraform-plugin-go/tfprotov6/tf6server.(*server).ReadDataSource(0xc00023a3c0, {0x1ba4508?, 0xc0008d7860?}, 0xc00011cb40)
        github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov6/tf6server/server.go:688 +0x26d
github.com/hashicorp/terraform-plugin-go/tfprotov6/internal/tfplugin6._Provider_ReadDataSource_Handler({0x19e1300, 0xc00023a3c0}, {0x1ba4508, 0xc0008d7860}, 0xc00042a700, 0x0)
        github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov6/internal/tfplugin6/tfplugin6_grpc.pb.go:572 +0x1a6
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000191000, {0x1ba4508, 0xc0008d7740}, {0x1bacc00, 0xc0003f6000}, 0xc00075b440, 0xc000319110, 0x22755a0, 0x0)
        google.golang.org/grpc@v1.66.0/server.go:1393 +0xe11
google.golang.org/grpc.(*Server).handleStream(0xc000191000, {0x1bacc00, 0xc0003f6000}, 0xc00075b440)
        google.golang.org/grpc@v1.66.0/server.go:1804 +0xe8b
google.golang.org/grpc.(*Server).serveStreams.func2.1()
        google.golang.org/grpc@v1.66.0/server.go:1029 +0x7f
created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 36
        google.golang.org/grpc@v1.66.0/server.go:1040 +0x125

Error: The terraform-provider-alz_v0.15.2.exe plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

However when modifying a policy one level higher, there's no issue.
policy_assignments_to_modify = {
    landing_zones = {
      policy_assignments = {
        Enable-DDoS-VNET = {
          enforcement_mode = "DoNotEnforce"
        }
      }
    }
  }

Thanks @JWilkinsonMB I'll take a look

Hi, I could not repro this - I tried with the following config:
provider "alz" {
	library_references = [
		{
			path = "platform/alz"
			ref  = "2024.10.0"
		}
	]
}

data "azapi_client_config" "current" {}

data "alz_architecture" "test" {
	name                     = "alz"
	root_management_group_id = data.azapi_client_config.current.tenant_id
	location                 = "swedencentral"
	policy_assignments_to_modify = {
		corp = {
			policy_assignments = {
				Deny-Public-IP-On-NIC = {
					enforcement_mode = "DoNotEnforce"
				}
			}
		}
	}
}

Please can you provide more of your config so I can try and troubleshoot? Thanks

Hi @matt-FFFFFF thanks for checking. Does this work for you as an MRE?
provider "alz" {
  library_references = [
    {
      path = "platform/alz"
      ref  = "2024.10.0"
    }
  ]
}

data "azapi_client_config" "current" {}

data "alz_architecture" "test" {
  name                     = "alz"
  root_management_group_id = data.azapi_client_config.current.tenant_id
  location                 = "swedencentral"
  policy_assignments_to_modify = {
    root = {
      policy_assignments = {
        Deploy-MDEndpoints = {
          enforcement_mode = "DoNotEnforce"
        }
      }
    }
  }
}

It looks like it doesn't make a difference what the hierarchy level is, so I started looking at the archetype overrides, which may still be related.
Up until I hit the error, all of the policies I was modifying were ones that I'd added to the archetype via an override. What triggered the error initially was trying to modify an assignment where it was defined on the base archetype, not the override.
I started chasing my tail trying to confirm that, but it led to the above, where a policy modified on the root triggers the crash.

Thanks for the additional info.
To confirm the repro steps are:

Create override archetype based on, say, root.

Add or remove some assignments.

Create custom architecture with the override archetype instead of the base

Modify a policy assignment that is part of the base archetype

Feel free to comment on this to set me on the right path!

Hi @matt-FFFFFF thanks for checking. Does this work for you as an MRE?

Hi I can repro with this code - working on identifying the issue

Hi @JWilkinsonMB
I have found the cause of the issue. In your repro steps the management group root does not exist in the architecture. The root MG in the default architecture is called alzroot.
Within the modifyPolicyAssignments() func we use a mathod call on the deployment to retrieve the deployment.HierarchyManagementGroup. the ModifyPolicyAssignment() method is then called to make the modifications.
https://github.com/Azure/terraform-provider-alz/blob/4eee62405ca9e299a50c54b697aff27763fc8e23/internal/provider/architecture_data_source.go#L178-L179
The alzlib method ManagementGroup is a simple function that returns a nil if the supplied name does not exist:
// ManagementGroup returns the management group with the given name.
func (h *Hierarchy) ManagementGroup(name string) *HierarchyManagementGroup {
	h.mu.RLock()
	defer h.mu.RUnlock()
	if mg, ok := h.mgs[name]; ok {
		return mg
	}
	return nil
}

The provider does not check for a nil response and that is where the error occurs.
I will make the fix today and publish a new release.

Thanks! That explanation also pointed me to where I was going wrong originally and why I saw the crash when I did. When adding the new policy to modify I was using the archetype name rather than management group ID. Despite going over the config it didn't click as up until that point the management group IDs and archetype names were the same.

authors: JWilkinsonMB matt-FFFFFF

repo: Azure/terraform-provider-alz


text:
[Tcgc] Fix getLibraryName for anonymous model which is derived from template

After https://github.com/microsoft/typespec/pull/4144, anonymous model type may also have templateMapper arguments. For this scenario, getLibraryName shall not try to generate name from arguments, otherwise may generate model with duplicated name.

All changed packages have been documented.

:white_check_mark: @azure-tools/typespec-client-generator-core

Show changes
@azure-tools/typespec-client-generator-core - fix ✏

Fix getLibraryName for anonymous model which is derived from template

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs

Do we need same fix in release/august branch?

authors: azure-sdk msyyc weidongxu-microsoft

repo: Azure/typespec-azure


text:
URI query parameters are not shown in secret preview

For some obscure reason query parameters are stripped from URIs when viewing an individual value of a secret through the Clusters panel.
How to reproduce

Create a secret like this and apply it:

apiVersion: v1
kind: Secret
metadata:
  name: test
stringData:
  URI: http://example.com/test?blah=sth

Reload the Clusters panel.

Click on the test secret in the tree view. You'll see that the URI value has been correctly Base64-encoded:

data:
  # -> http://example.com/test?blah=sth
  URI: bW9uZ29kYjovL2V4YW1wbGUuY29tL3Rlc3Q/YmxhaD1zdGg=

Now click on URI (the individual value nested inside test) in the tree view:

mongodb://example.com/test

As you can see, the URI does not have any query parameters anymore.

This is a bug with how we pass the base64 encoded data around.  We currently stuff it into a URI.  But the base64 encoding of your URL-with-query includes a slash.  And we don't handle that correctly, resulting in truncation when we try to pull it out of the URI again.
Thanks for flagging this - looking at a fix now.

authors: itowlson shroudedcode

repo: Azure/vscode-kubernetes-tools


text:
Error while deploying to Azure App service

We are trying to Deploy Azure App Service from GitHub Actions using Windows Self-Hosted Action Runner
Using task - https://github.com/Azure/webapps-deploy
workflow -
- name: Deploy to Azure WebApp
uses: Azure/webapps-deploy@v2
with:
# app-name: ${{ env.AZURE_WEBAPP_NAME }}
publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
package:  './myapp/PackageTmp'
We are getting below error -
Deployment Failed with Error: Error: Failed to deploy web package to App Service. SyntaxError: Error parsing E:\actions-runner\AR_work_actions\Azure\webapps-deploy\v2\node_modules\tunnel\package.json: Unexpected token < in JSON at position 2
Can you please suggest.
Thanks

Hey @vinaysandela Can you please confirm if

The app-name field is commented or uncommented because deployment is going to fail without it.
Is it running fine on github hosted runners?(windows-latest/ ubuntu-latest)?
The package path provided is correct or not.

Also please check if the dependencies required by the app are being fulfilled or not. Visit example workflows for more context. please let us know if it works.

@vinaysandela any updates on this issue? Can you share your workflow if the issue still persists.

@BALAGA-GAYATRI I got the same issue on my self-hosted runners.
Package deployment using ZIP Deploy initiated.
Error: Failed to deploy web package to App Service.
Error: Deployment Failed with Error: Error: Failed to deploy web package to App Service.
SyntaxError: Error parsing /opt/actions-runner/_work/_actions/azure/webapps-deploy/v2/node_modules/tunnel/package.json: Unexpected token < in JSON at position 2

It seems there is a unresolved git diff in the package.json of tunnel in the current
v2 release.
{
<<<<<<< HEAD
  "name": "tunnel",
  "version": "0.0.6",
=======
  "_from": "tunnel@0.0.6",
  "_id": "tunnel@0.0.6",
  "_inBundle": false,
  "_integrity": "sha512-1h/Lnq9yajKY2PEbBadPXj3VxsDDu844OnaAo52UVmIzIvwwtBPIuNvkjuzBlTWpfJyUbG3ez0KSBibQkj4ojg==",
  "_location": "/tunnel",
  "_phantomChildren": {},
  "_requested": {
    "type": "version",
    "registry": true,
    "raw": "tunnel@0.0.6",
    "name": "tunnel",
    "escapedName": "tunnel",
    "rawSpec": "0.0.6",
    "saveSpec": null,
    "fetchSpec": "0.0.6"
  },
  "_requiredBy": [
    "/typed-rest-client"
  ],
  "_resolved": "https://registry.npmjs.org/tunnel/-/tunnel-0.0.6.tgz",
  "_shasum": "72f1314b34a5b192db012324df2cc587ca47f92c",
  "_spec": "tunnel@0.0.6",
  "_where": "E:\\Repos\\GHActions\\webapps-deploy\\node_modules\\typed-rest-client",
  "author": {
    "name": "Koichi Kobayashi",
    "email": "koichik@improvement.jp"
  },
  "bugs": {
    "url": "https://github.com/koichik/node-tunnel/issues"
  },
  "bundleDependencies": false,
  "deprecated": false,
>>>>>>> 798e43877120eda6a2a690a4f212c545e586ae31
  "description": "Node HTTP/HTTPS Agents for tunneling proxies",
  "devDependencies": {
    "mocha": "^5.2.0",
    "should": "^13.2.3"
  },
  "directories": {
    "lib": "./lib"
  },
  "engines": {
    "node": ">=0.6.11 <=0.7.0 || >=0.7.3"
  },
  "homepage": "https://github.com/koichik/node-tunnel/",
  "keywords": [
    "http",
    "https",
    "agent",
    "proxy",
    "tunnel"
  ],
  "license": "MIT",
  "main": "./index.js",
  "name": "tunnel",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/koichik/node-tunnel.git"
  },
  "scripts": {
    "test": "mocha"
<<<<<<< HEAD
  },
  "devDependencies": {
    "mocha": "^5.2.0",
    "should": "^13.2.3"
  },
  "engines": {
    "node": ">=0.6.11 <=0.7.0 || >=0.7.3"
  }

,"_resolved": "https://registry.npmjs.org/tunnel/-/tunnel-0.0.6.tgz"
,"_integrity": "sha512-1h/Lnq9yajKY2PEbBadPXj3VxsDDu844OnaAo52UVmIzIvwwtBPIuNvkjuzBlTWpfJyUbG3ez0KSBibQkj4ojg=="
,"_from": "tunnel@0.0.6"
}
=======
  },
  "version": "0.0.6"
}
>>>>>>> 798e43877120eda6a2a690a4f212c545e586ae31

I've been deploying webapps-deploy@v2 fine till about 30 days ago then this error started occurring. Looking at files on the server we confirmed that the package.json file looked like @rbinder-vg's file.
Can confirm rolling back to webapps-deploy@v1 let's us get past this issue.

I am facing the same issue. And I can confirm @rbinder-vg's finding.

This issue should be re-opened and addressed. I am also facing the same error/problem and have had to resort back to webapps-deploy@v1 to get it working.

We have fixed this issue in our last release, please try using v2 and see if it's working fine.
Closing this, please re-open or create new issue in case of any issues.

authors: BALAGA-GAYATRI DeLuca-Marco ITSWA WadeParallon rbinder-vg shpraka vinaysandela

repo: Azure/webapps-deploy


text:
Investigate enforcing confidential client per user in some confidential client scenarios

Refer : https://github.com/AzureAD/microsoft-authentication-library-for-go/pull/117#discussion_r553580438 and https://github.com/AzureAD/microsoft-authentication-library-for-go/pull/117#discussion_r553581029

Insufficient context. MSAL should work both when using singleton CCA and when using 1 CCA per request.


text:
[Bug] MSAL4J interactive flow fails with Chrome version 123

Library version used
1.14.3
Java version
Amazon Corretto 8 version 1.8.0_392
Scenario
PublicClient (AcquireTokenInteractive, AcquireTokenByUsernamePassword)
Is this a new or an existing app?
The app is in production, and I have upgraded to a new version of MSAL
Issue description and reproduction steps

Make sure Google Chrome is updated to version 123
Set Google Chrome as default browser
Make sure the app registration used has http://localhost as redirect URI in Desktop and Mobile platform in Entra ID
Make a simple call that uses default browser to interactively acquire token from localhost, like the snippet below
Complete login process until redirected back to http://localhost

Relevant code snippets
Reproducible with the example in https://learn.microsoft.com/en-us/entra/msal/java/getting-started/acquiring-tokens-interactively

PublicClientApplication publicClientApplication =
        PublicClientApplication
                .builder(CLIENT_ID)
                .authority(AUTHORITY)
                .build();

InteractiveRequestParameters parameters = InteractiveRequestParameters
        .builder(new URI("http://localhost"))
        .scopes(scope)
        .build();

IAuthenticationResult result = publicClientApplication.acquireToken(parameters).join();

Expected behavior
Expected behavior that Google Chrome, after login process, connects to localhost and the PublicClientApplication is able to acquire the token.
This used to work up to Chrome version 122, but since version 123 Chrome fails to connect to the localhost address - there is an additional preflight request to the same address in the newer version that succeeds but the actual request fails.
If you think this is a problem with Chrome rather than MSAL4J, please comment and, I suppose, close issue.
Identity provider
Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)
Regression
No response
Solution and workarounds

Obviusly: Changing default browser to, e.g., Edge or Firefox fixes problem.

For Google Chrome: if started with

chrome -args --disable-features=PrivateNetworkAccessForNavigations,PrivateNetworkAccessForNavigationsWarningOnly
login works as expected

Hello @KodarLiteIbland : I'm not able to reproduce your issue.

I had been on Chrome version 122, and using the code you posted and two different users I could get a token
I then restarted chrome and updated to 123.0.6312.59, and could still get tokens without issue

Is there any specific error message from MSAL or Chrome?
Since disabling that PrivateNetworkAccessForNavigations feature seems to resolve it, then the issue is probably with the security settings in Chrome and some setting may have become more strict after the update.

Hi @Avery-Dunn
Interesting that you could not reproduce the error, would it help if I paste full code for a reproducing sample?
Chrome reports ERR_CONNECTION_REFUSED, after which MSAL gets MsalClientException "No authorization code was returned from the server".

BTW, there are some open issues for Chromium project with similar issues in other products as well, so it might be that this is addressed in future updates
https://issues.chromium.org/issues?q=status:open PrivateNetworkAccessForNavigations

The full code could help, but I don't think this is an MSAL issue. What you've already posted is pretty much all of the browser interaction that MSAL has for the interactive flow, and as you mention there are reports of similar issues in a variety of scenarios.
In particular at that link there is issue 330594669, which pretty much describes your issue exactly: upgrade to 123, redirect to localhost, get ERR_CONNECTION_REFUSED. That issue is about gcloud, and mentions that it's affection Python clients also, so it's very unlikely we coincidentally have an unrelated bug only in MSAL Java.
I guess I'll leave this open for now in case anything changes in the next few days, but this is probably not an MSAL issue and there's not much we can recommend other than that workaround you've already found.

Hi @Avery-Dunn
Sorry for late answer, but yes, the reproducing sample was more or less those lines + a little setup, so probably not relevant.
Chromium issue issue 330594669 was already reported fixed in Chrome Canary, and I can confirm that the Interactive Flow works again in Canary too. So apparently this was an unwanted side-effect that will be removed from official Chrome soon, and (hopefully) not at all to other Chromium based browsers like Edge.
You can decide whether to close issue now, or when official Chrome is updated. Thanks for your time!

Glad to hear it's working in that Canary version, thanks for testing it out! If you run into any other issues, feel free to re-open this thread or open a new one.

authors: Avery-Dunn KodarLiteIbland


text:
Some values are now resulting in InvaildState during login

Please follow the issue template below. Failure to do so will result in a delay in answering your question.

Library

[x] msal@1.3.2 or @azure/msal@1.x.x
[ ] @azure/msal-browser@2.x.x
[ ] @azure/msal-angular@0.x.x
[ ] @azure/msal-angular@1.x.x
[ ] @azure/msal-angularjs@1.x.x

Important: Please fill in your exact version number above, e.g. msal@1.1.3.
Framework
AngularJS 1.x and React, but those are not at play in this scenario
Description
Updated from 1.2.2 to 1.3.2 yesterday and noticed this immediately in development.
I've found that certain values for the state property are now causing loginRedirect to fail with an Invalid State
I've found that the state validation is also now failing when using it to roundtrip the final url to re-direct the user to when there are certain characters in the query string.
state: "http://localhost:9000/home" works as expected.
However: state: "http://localhost:9000/sessions?t=%257B%2522from%2522%253A%25222020-07-19T08%253A30%253A00-07%253A00%2522%252C%2522to%2522%253A%25222020-07-23T18%253A00%253A00-07%253A00%2522%257D&g=%255B%2522available-rsvp-only%2522%255D" results in:
ClientAuthError: Invalid state. eyJpZCI6Ijc5ODdlMTJmLTk2M2YtNDBkMC1hM2QxLTRiOGVjZTNlMmM1NyIsInRzIjoxNTk2MjE4NDA2LCJtZXRob2QiOiJyZWRpcmVjdEludGVyYWN0aW9uIn0=|http://localhost:9000/sessions?t=%7B%22from%22%3A%222020-07-19T08%3A30%3A00-07%3A00%22%2C%22to%22%3A%222020-07-23T18%3A00%3A00-07%3A00%22%7D&g=%5B%22available-rsvp-only%22%5D, state expected : null
Error Message
ClientAuthError: Invalid state. eyJpZCI6Ijc5ODdlMTJmLTk2M2YtNDBkMC1hM2QxLTRiOGVjZTNlMmM1NyIsInRzIjoxNTk2MjE4NDA2LCJtZXRob2QiOiJyZWRpcmVjdEludGVyYWN0aW9uIn0=|http://localhost:9000/sessions?t=%7B%22from%22%3A%222020-07-19T08%3A30%3A00-07%3A00%22%2C%22to%22%3A%222020-07-23T18%3A00%3A00-07%3A00%22%7D&g=%5B%22available-rsvp-only%22%5D, state expected : null
at ClientAuthError.AuthError [as constructor] (webpack-internal:///./node_modules/msal/lib-es6/error/AuthError.js:30:24)
at new ClientAuthError (webpack-internal:///./node_modules/msal/lib-es6/error/ClientAuthError.js:114:24)
at Function.ClientAuthError.createInvalidStateError (webpack-internal:///./node_modules/msal/lib-es6/error/ClientAuthError.js:159:12)
at UserAgentApplication.saveTokenFromHash (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:1787:93)
at UserAgentApplication.processCallBack (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:1172:23)
at UserAgentApplication.handleRedirectAuthenticationResponse (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:1269:10)
at new UserAgentApplication (webpack-internal:///./node_modules/msal/lib-es6/UserAgentApplication.js:141:14)
at eval (webpack-internal:///./app/scripts/msal/msal-auth-service.ts:21:15)
at Module../app/scripts/msal/msal-auth-service.ts (http://localhost:9000/app.bundle.ada3.js?ada3971f6bf3f34ab426:5717:1)
at webpack_require (http://localhost:9000/app.bundle.ada3.js?ada3971f6bf3f34ab426:774:30)
Security

[ ] Is this issue security related?
Not to my knowledge

Regression

[ ] Did this behavior work before?
Version: 1.2.2

MSAL Configuration
export const msalConfig: Configuration = {
    auth: {
        clientId: Resources.ApplicationId,
        authority: `https://${Resources.AadTenantName}.b2clogin.com/${Resources.AadTenantName}.onmicrosoft.com/${Resources.Aadb2cPolicy}`,
        redirectUri: `${window.location.origin}${Resources.LoginPage}`,
        postLogoutRedirectUri: window.location.origin,
        validateAuthority: false,
        navigateToLoginRequestUrl: false
    },
    cache: {
        cacheLocation: 'localStorage',
        storeAuthStateInCookie: false
    }
};

export const loginRequest: AuthenticationParameters = {
    scopes: [Resources.ApplicationId],
    extraQueryParameters: {
        appId: Resources.ApplicationId
    }
};

Reproduction steps
export const signIn = (state?: string): void => {
    const request = { state, ...loginRequest };
    if (!msalApp.getLoginInProgress()) msalApp.loginRedirect(request);
};

Expected behavior
Login works and properly round trips the passed in URL as state
Browsers/Environment

[ ] Chrome
[ ] Firefox
[X] Edge 86.0.587.0 (Official build) dev (64-bit)
[ ] Safari
[ ] IE
[ ] Other (Please add browser name here)

Hi @gavinbarron , thanks for raising this issue. We'll investigate and follow-up when we have more information.

I've found that the state validation is also now failing when using it to roundtrip the final url to re-direct the user to when there are certain characters in the query string.

Setting navigateToLoginRequestUrl to true is a way to redirect the user back to the page they were on when they performed the redirect. Have you considered enabling that option instead of providing the URL in the state parameter?

@technical-boy using navigateToLoginRequestUrl: true is not a viable option in our use case.
We're using the id_token to establish identity and have custom authorization logic that we need to run before granting access to our site navigateToLoginRequestUrl: true would prevent us from running our custom logic.

Hi @gavinbarron . Is the state value your are passing into the request URI encoded by your application? MSAL will perform URI encoding for all query parameters, including state, so it's not necessary to URI encode them before passing them into the configuration object.
Can you try passing in an un-encoded state value and let us know if that works? Thanks!

We're just reading the exact value of window.location.href, it has encoded values because, well, they were encoded by the browser.

I think the bot is only looking at comments not triaging activities.

Yes, @gavinbarron. I've removed the label given we are still looking into this issue.

Closing, fixed in #2125 and released in v 1.4.0

Thanks for this. Will upgrade our dependencies on Monday :)

authors: gavinbarron technical-boy