text:
Docs.MS Release Updates for Azure.Communication.Sms

Update docs metadata and targeting for release of Azure.Communication.Sms

Docs Build status updates of commit ed711d4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

api/overview/azure/communication.sms-readme-pre.md
:white_check_mark:Succeeded
View

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

source: gharchive/pull-request

authors: VSC-Service-Account azure-sdk

repo: Azure/azure-docs-sdk-dotnet

license_type: permissive

license_source: github-api


text:
Docs.MS Release Updates for Azure.Security.KeyVault.Secrets

Update docs metadata and targeting for release of Azure.Security.KeyVault.Secrets

Docs Build status updates of commit 018bbf0:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

api/overview/azure/security.keyvault.secrets-readme-pre.md
:white_check_mark:Succeeded
View

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


text:
Defaulting to source-generation

Issue describing the changes in this PR
resolves #1906
Pull request checklist

[x] My changes do not require documentation changes

[ ] Otherwise: Documentation issue linked to PR

[ ] My changes should not be added to the release notes for the next release

[x] Otherwise: I've added my notes to release_notes.md

[x] My changes do not need to be backported to a previous version

[ ] Otherwise: Backport tracked by issue/PR #issue_or_pr

[x] I have added all required tests (Unit tests, E2E tests)

Additional information
Additional PR information

Still doing some local validation/testing as well, keeping in draft.

Blocked by https://github.com/Azure/azure-functions-host/issues/9536 - I don't believe we can release this without the release of this host change.

Blocked by Azure/azure-functions-host#9536 - I don't believe we can release this without the release of this host change.

Are we really blocked on that PR? I am positive the setting is enabled on stamp level for all stamps. @soninaren Can you confirm.

Confirmed offline that this is not blocked - host PR for defaulting is not done, but all stamps have worker-indexing enabled so we can proceed.

authors: kshyju satvu

repo: Azure/azure-functions-dotnet-worker

license: MIT


text:
NATS.io as topic sender

What binding does your question apply to, if any? (e.g. Blob Trigger, Event Hub Binding, etc)
Topic Trigger
Question
So the deal is that I need to listen to topics from NATS using Python.
I found this guy krvarma that did it with C#, but I need it to be in Python and I don't know how to do it (just started learning about Azure Functions).
I used the bus topic trigger already, but sending message from the azure console, and not from nats, any help I would appreciate.

Hello @JuniorZilles, unfortunately we do not have a plan to support NATS in the near future.
cc: @vrdmr for further information why it wouldn't work for Python as it does in .NET

Thank you @stefanushinardi!
@vrdmr can you explain why it wouldn't work?

source: gharchive/issue

authors: JuniorZilles stefanushinardi

repo: Azure/azure-functions-python-worker


text:
Update docker-compose.yaml to fix the issue that is reported for dockerised-quickstart tutorial

The dockerised-quickstart part of the tutorial is not updating the data in Azure tables (the connector and producer is working fine).
There is a mismatch in the topic name between the producer and connector and upon making this change it started working

The dockerised-quickstart part of the tutorial is not updating the data in Azure tables (the connector and producer is working fine).
There is a mismatch in the topic name between the producer and connector and upon making this change it started working

resolves #22

repo: Azure/azure-kusto-labs


text:
[Hub Generated] Review request for Microsoft.Devices to add version preview/2020-09-01-preview

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

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

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

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

Contribution checklist:

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

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

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

Adding new API(s)
Adding a new API version
Adding a new service

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

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

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

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

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

@akning-ms copying you here since you have context.

@mrohera , could you fix the CI check failures? Please starts from avocado errors.

@akning-ms are these errors due to the recommended versioning pattern that is not supported?

@akning-ms are these errors due to the recommended versioning pattern that is not supported?

No, it is due to your PR still change for /preview/2020-09-01-preview/iotdps.json. it should be /preview/2020-09-01-preview**.1**/iotdps.json

Thanks @akning-ms, I've fixed it. I accidentally updated the wrong file.

@akning-ms please have a look now and let me know if these failures are expected?

@akning-ms please have a look now and let me know if these failures are expected?

The avocado error is still there, you need to also remove /preview/2020-09-01-preview/iotdps.json  from PR to fix it.

ARM review is not required as it is just add optional properties as this PR #11809

Looks ARM still not support new version format which still in progress. The PR will hold until ARM support. will update this in breaking change intake form.

Closing PR since this style of API versioning is unsupported.

authors: akning-ms mrohera raych1

repo: Azure/azure-rest-api-specs


text:
PII Types for 3.1-Preview.4

Add support for PII type filters as a request param - takes in a comma separated list of strings describing the types we support

Could you also update the PII response example?

Could you also update the PII response example?

@iscai-msft could you help get this PR merged?

@iscai-msft could you help get this PR merged?

@tjprescott can we get this merged ?

@tjprescott can we get this merged ?

authors: assafi maririos suhas92 thediris


text:
Fix library configuration bug in bigDataPool.json

Fixed the model reference for LibraryInfo. This bug is rendering this API useless. So fixing it in same version.
Added missing property lastSucceededTimestamp.
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

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

What's the purpose of the update?

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

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

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

Contribution checklist:

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

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

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

Adding new API(s)
Adding a new API version
Adding a new service

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

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

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

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

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

Hi @mahariha, one or multiple breaking change(s) is detected in your PR. Please check out the breaking change(s), and provide business justification in the PR comment and @ PR assignee why you must have these change(s), and how external customer impact can be mitigated. Please ensure to follow breaking change policy to request breaking change review and approval before proceeding swagger PR review.
Action: To initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
If you want to know the production traffic statistic, please see ARM Traffic statistic.
If you think it is false positive breaking change, please provide the reasons in the PR comment, report to Swagger Tooling Team via https://aka.ms/swaggerfeedback.

Hi @mahariha, one or multiple breaking change(s) is detected in your PR. Please check out the breaking change(s), and provide business justification in the PR comment and @ PR assignee why you must have these change(s), and how external customer impact can be mitigated. Please ensure to follow breaking change policy to request breaking change review and approval before proceeding swagger PR review.
Action: To initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
If you want to know the production traffic statistic, please see ARM Traffic statistic.
If you think it is false positive breaking change, please provide the reasons in the PR comment, report to Swagger Tooling Team via https://aka.ms/swaggerfeedback.

Bigdatapool.json is referring incorrect model for libraryInfo which is rendering the object useless. This change addresses the bug. Hence it is done in same version.


text:
[Hub Generated] Review request for Microsoft.LabServices to add version preview/2021-11-15-preview

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

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

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

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

Contribution checklist:

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

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

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

Change to data plane APIs
Adding new properties
All removals

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

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

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

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

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

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

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

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

@weidongxu-microsoft - the manifest changes have rolled out, can you please merge this now? Thanks!


text:
release 2023-04-01 swagger to public repo

ARM (Control Plane) API Specification Update Pull Request
PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

[1] ARM review queue (for merge queues, see [4])
The PRs are processed by time opened, ascending. Your PR may show up on 2nd or later page.
If you addressed Step 1 from the diagram and your PR is not showing up in the queue, ensure the label ARMChangesRequested
is removed from your PR. This should cause the label WaitForARMFeedback to be added.
[2] https://aka.ms/azsdk/support/specreview-channel
[3] List of SDK breaking changes approvers in pinned Teams announcement
[4] public repo merge queue, private repo merge queue (for ARM review queue, [1])
If you need further help with anything, see Getting help section below.
Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

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

edit this with your clarification

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

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

Breaking changes review (Step 1)

If the automation determines you have breaking changes, i.e. Step 1 from the diagram applies to you,
you must follow the breaking changes process.
IMPORTANT This applies even if:

The tool fails while it shouldn't, e.g. due to runtime exception, or incorrect detection of breaking changes.
You believe there is no need for you to request breaking change approval, for any reason.
Such claims must be reviewed, and the process is the same.

ARM API changes review (Step 2)

If this PR is in purview of ARM review then automation will add the ARMReview label.
If you want to force ARM review, add the label yourself.
Proceed according to the diagram at the top of this comment.

Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.
Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
Getting help

For general PR approval workflow, see the diagram at the top of this comment.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

This is publishing a previously used but not published api version 2023-04-01. As discussed in today's breaking change review office hour, that's the reason we got some breaking change tags on the 2023-09-01 PR. This is required to be done. I'll ping the breaking change reviewers about this PR if there are any breaking change identified.

Base commit is not missing. The diff can be viewed here: https://github.com/Azure/azure-rest-api-specs/pull/25959/commits/155f9ab17f53bcbfed24f730f6d857c902ff39de

The identified breaking change is already approved here https://github.com/Azure/azure-rest-api-specs-pr/pull/12762 .

The initial 2023-04-01 PR approved in azure-rest-api-specs-pr : https://github.com/Azure/azure-rest-api-specs-pr/pull/11959

Hi @rkmanda , it would be muchly appreciated if anyone from your side can review this sooner. This 2023-04-01 is an already in-use version for a few months and should be all good from all aspects.

/pr RequestMerge

/azp run

authors: raosuhas zaowang-ms


text:
Search preview version 2024-03-01-preview

Data Plane API - Pull Request
Another BYOV preview
API Info: The Basics
Target Features:

Support narrow data types for vector values and vector quantization
Support reduction of vector field storage overhead via _source exclusions.

CC @JeffreyRichter for the breaking change review.

Why the new "required" properties? These are breaking and should be avoided.

Why the new "required" properties? These are breaking and should be avoided.

Similar to other Azure services, we had to encapsulate the SearchError within an Error property. While our service successfully accomplishes this, Swagger fails to include it. For instance, the service returns:
{
"error": {
"message": "",
"code": "",
"details": "<optional array of SearchError (this type)>"
}
}
However, Swagger only exhibits the following:
{
"message": "",
"code": "",
"details": "<optional array of SearchError (this type)>"
}

OK, I approved it

@heaths, thanks for all the feedback, we have addressed it and updated this PR. Can you please add the "APIStewardshipBoard-SignedOff" tag.
cc: @jhendrixMSFT

I think @JeffreyRichter has the final call for adding APIStewardshipBoard-SignedOff

I think @JeffreyRichter has the final call for adding APIStewardshipBoard-SignedOff

@jhendrixMSFT can you please merge this PR?

authors: JeffreyRichter jhendrixMSFT sazeesha098


text:
actionRules - AlertsManagement

adding new resource type actionRules in AlertsManagement RP
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

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

ARM API Review Checklist

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

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

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

Hello!!
The Rest API Specs team wishes everyone a happy holiday and would like to kindly inform you that responses and review to Pull request will be delayed during the holiday period (now -> 2nds of January) to allow for Awesome reviewers to have an awesome time with their families during the holidays!
Thanks and Have a WONDERFUL HOLIDAY

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Automation for azure-sdk-for-node

Automation for azure-sdk-for-java

@roramc The name contains "privatepreview".. if this is indeed a private preview that why not use the private repo to drive this?

authors: AutorestCI azuresdkci praries880 roramc


text:
A series of Public swagger update

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

Contribution checklist:

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

ARM API Review Checklist

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

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

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

Automation for azure-sdk-for-python

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-js

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

Automation for azure-sdk-for-java

@Yiliu-microsoft  Please make sure all checks are green.

Is this a duplicate of 6064? Which one should we review

@Yiliu-microsoft As I understand, this PR was abandoned, right? Can you please confirm and close it? Azure team is reviewing 6064 already, and this is confusing.

authors: AutorestCI KrisBash Yiliu-microsoft azuresdkci hvermis


text:
Can we update DateTime::Parse(string, DateFormat::Rfc3339) to allow space in place of T?

So far, it is the only known input that has space in it instead of "T". If we have more, we can add (internally first, I think) another parse format support. It is easy to modify the parser to allow space there.
But, I would check with Jeffrey first to ask if he thinks it is safe to update the parser, and whether that still can be called DateFormat::Rfc3339.
RFC 3339 itself says:
"NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character."
https://www.rfc-editor.org/rfc/rfc3339
Originally posted by @antkmsft in https://github.com/Azure/azure-sdk-for-cpp/pull/4167#discussion_r1042897351
FWIW, .NET's DateTime.Parse() would parse "2021-02-03 12:34:56", ours would not.

Do we have a need to allow the space instead of T? If so, what is the use case?

It is only needed by AzureCliCredential, in one place. Currently, we do search-for-space-and-replace-with-T there: https://github.com/Azure/azure-sdk-for-cpp/blob/456a8e9fb9154d223f07b7d01df890a1a17b714e/sdk/identity/azure-identity/src/token_credential_impl.cpp#L184-L194
Should we leave it only at that one place, or is it ok to update the DateTime parser?

Leave it for now. This shouldn't happen often, so we hopefully won't need to change our DateTime parser.

Thanks Jeffrey!
cc @ahsonkhan

What format does the DateTime in AzureCliCredential adhere to? Is the datetime format they use documented somewhere?
Our Rfc3339 datetime format seems to be too strict. Rfc3339 is a profile of ISO8601 but allows some more flexibility beyond what ISO 8601 states. Given the enum name is Rfc3339 and not ISO8601, we may want to be less strict.

Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.

AzureCliCredential has to work with what az account get-access-token --output json ... command gives it. And that is apparently, a string, as you'd expect from a datetime, but with a space instead of T. I think it ultimately comes from MSAL for Pyhton library. I don't think it is explicitly documented. Even if they fix it, we'd still have to support older versions.
I agree, adding support for space is probably the least problematic things we can add support for - it is widely used. Even .NET's DateTime.Parse() supports it. But the fact that up to this moment no one has ran into this limitation, does also indicate that it is not used very frequently in the SDK space. And that argument has some strength for us, as our DateTime is not a general purpose DateTime, but the one that is used for communications with Azure services. If we add it, we won't be able to take it back, and will have to support it, although realistically it won't cost us much.
I understand Jeffrey's decision here, not adding it yet leaves us with more potential options for the future and limits the scope we have to support. I'd say, let's see if more places need support for space in datetimes, or if customer would want it, and then we can add it, and we'll update the place in the token parser where we replace space with 'T' before giving it to DateTime parser. I don't think it is "never", I think it is "maybe later".

is not a general purpose DateTime, but the one that is used for communications with Azure services

We do need it for communication with Azure services, here. Azure Cli Credential bares that out. Rather than having custom string find-replace logic (which we are needing to do anyway), the appropriate fix would be to have the DateTime::Parse method be accurate to what it is documented as doing. I am not saying we should support every single test case, but allowing T OR <space> seems reasonable.
Change this line:
https://github.com/Azure/azure-sdk-for-cpp/blob/3fe9c27c412fcb46d0399f27b900a45e7fbee1c6/sdk/core/azure-core/src/datetime.cpp#L607
- if (cursor < DateTimeLength && (dateTime[cursor] == 'T' || dateTime[cursor] == 't'))
+ // Unlike ISO 8601, RFC 3339 allows for a space character, and that's needed by Azure Cli Credential
+ if (cursor < DateTimeLength && (dateTime[cursor] == 'T' || dateTime[cursor] == 't' || dateTime[cursor] == ' '))

https://github.com/Azure/azure-sdk-for-cpp/blob/3fe9c27c412fcb46d0399f27b900a45e7fbee1c6/sdk/core/azure-core/inc/azure/core/datetime.hpp#L171-L182
Also, we have a DateFormat which explicitly says parse this date according to Rfc 3339 and then we are rejecting an input that is valid according to the RFC. I would consider that something worth fixing.
https://medium.easyread.co/understanding-about-rfc-3339-for-datetime-formatting-in-software-engineering-940aa5d5f68a
https://ijmacd.github.io/rfc3339-iso8601/

@ahsonkhan, both your and @JeffreyRichter arguments make sense to me. Jeffrey's from a practical point of view, yours from the theoretical and from specification purity point of view. My instinct is more with Jeffrey, since once released, we have less options to change it in the future. Although in this case, it makes good sense, and it is not likely it is going to be problematic for us in the future, plus I like mimicking the .NET behavior. But in the end, I do not have that strong of an opinion. Either is fine with me - as I said, I kind of agree with you both. So far, I am fine with find-and-replace on that one instance in the code. Plus it makes Identity backwards-compatible for a few more versions.
It looks like you are more passionate about this, and I respect that. If you can come to an agreement with Jeffrey about this, and make sure we are really not missing anything and won't run into any unforeseen problems, I will be happy to change it. Just do that and tell me the conclusion, and I'll make a PR that adds ' ' where 'T' is allowed and a few updates to unit test.

Space it is. I'll make a PR.

authors: JeffreyRichter ahsonkhan antkmsft

repo: Azure/azure-sdk-for-cpp


text:
Fixed datalake/file service protocol layer remaining issues.

Fixes https://github.com/Azure/azure-sdk-for-cpp/issues/435

Fixes https://github.com/Azure/azure-sdk-for-cpp/issues/434

Fixes https://github.com/Azure/azure-sdk-for-cpp/issues/383.

Fixes https://github.com/Azure/azure-sdk-for-cpp/issues/392


text:
Update experimental branch to be ready for merge with master

Return old packages that had been removed from the branch for clarity, and add deprecation tags to them.

I've taken a slightly different strategy here, and I've just cherry-picked the relevant commits to the generator and profileBuilder onto my fork's dev branch. From there, I'll submit another PR with the generated packages.

repo: Azure/azure-sdk-for-go


text:
Remove redundant auth error content

ChainedTokenCredential errors
Before
DefaultAzureCredential authentication failed. failed to acquire a token.
Attempted credentials:
        EnvironmentCredential: missing environment variable AZURE_TENANT_ID
        WorkloadIdentityCredential: no client ID specified. Check pod configuration or set ClientID in the options
        ManagedIdentityCredential authentication failed. ManagedIdentityCredential authentication failed. authentication failed
GET http://169.254.169.254/metadata/identity/oauth2/token
--------------------------------------------------------------------------------
RESPONSE 401 Unauthorized
--------------------------------------------------------------------------------
{
  "error": "unauthorized"
}
--------------------------------------------------------------------------------
To troubleshoot, visit https://aka.ms/azsdk/go/identity/troubleshoot#managed-id
GET http://169.254.169.254/metadata/identity/oauth2/token
--------------------------------------------------------------------------------
RESPONSE 401 Unauthorized
--------------------------------------------------------------------------------
{
  "error": "unauthorized"
}
--------------------------------------------------------------------------------
To troubleshoot, visit https://aka.ms/azsdk/go/identity/troubleshoot#managed-id
GET http://169.254.169.254/metadata/identity/oauth2/token
--------------------------------------------------------------------------------
RESPONSE 401 Unauthorized
--------------------------------------------------------------------------------
{
  "error": "unauthorized"
}
--------------------------------------------------------------------------------

After
DefaultAzureCredential: failed to acquire a token.
Attempted credentials:
        EnvironmentCredential: missing environment variable AZURE_TENANT_ID
        WorkloadIdentityCredential: no client ID specified. Check pod configuration or set ClientID in the options
        ManagedIdentityCredential authentication failed.
                GET http://169.254.169.254/metadata/identity/oauth2/token
                --------------------------------------------------------------------------------
                RESPONSE 401 Unauthorized
                --------------------------------------------------------------------------------
                {
                  "error": "unauthorized"
                }
                --------------------------------------------------------------------------------
                To troubleshoot, visit https://aka.ms/azsdk/go/identity/troubleshoot#managed-id

Lone credentials built on MSAL
Before
ClientSecretCredential authentication failed. FromClientSecret(): http call(https://login.microsoftonline.com/fake-tenant/oauth2/v2.0/token)(POST) error: reply status code was 418:
no tokens here
Request information not available
--------------------------------------------------------------------------------
RESPONSE I'm a teapot
--------------------------------------------------------------------------------
no tokens here
--------------------------------------------------------------------------------
To troubleshoot, visit https://aka.ms/azsdk/go/identity/troubleshoot#client-secret

After
ClientSecretCredential authentication failed.
Request information not available
--------------------------------------------------------------------------------
RESPONSE 418: I'm a teapot
--------------------------------------------------------------------------------
no tokens here
--------------------------------------------------------------------------------
To troubleshoot, visit https://aka.ms/azsdk/go/identity/troubleshoot#client-secret

Looks way better!

authors: chlowell jhendrixMSFT


text:
Add ADFS / Azure Stack Support

On-prem active directory instance support
Requested by CLI / PSH for .NET and Python

Assigning to @g2vinay who is driving investigation for Identity v-team

repo: Azure/azure-sdk-for-java


text:
[FEATURE REQ] Support passwordless connection for Azure Redis cache in Spring M2- Connect to multiple Azure Redis servers

Is your feature request related to a problem? Please describe.
We have supported passwordless connections with Azure Redis Cache in Spring with this issue and PR.
The supported scopes are: Spring Boot 2.x + jedis 3.8.x.
Now we would like to make it can work to create multiple connections with different Azure Redis servers.
Describe the solution you'd like

[x]  1. Code validation

validate whether it's possible to use bean-based configuration to connect multiple Azure Redis servers with password-less authentication.

If yes, is there any code change? What's the complexity? How much the effort for users to use?
If no, what's the reason. What should we do if we want to support it?

Yes, and there is no code change.

[x] 2. Code Design/ Code Change

It depends Code validation's result.

No code change/Design

[ ] 3. Samples/Docs

[ ]  Create samples in https://github.com/Azure-Samples/azure-spring-boot-samples to demonstrate using passwordless authentication connect multiple Azure Redis servers.
[ ]  Create a reference doc to demonstrate steps using passwordless authentication connect multiple Azure Redis servers.

Milestone ETA
Goal
Issue

Milestone 1 -- Jan
Support Spring Boot 2.x + Jedis
https://github.com/Azure/azure-sdk-for-java/issues/31350

Milestone 2 -- April
Connect to multiple Azure Redis servers
https://github.com/Azure/azure-sdk-for-java/issues/33227

Milestone 3 -- June 23
Support Spring Boot 3 + Lettuce
https://github.com/Azure/azure-sdk-for-java/issues/33228

Milestone 4 -- July 23
Support Spring Boot 3.1 + Jedis
https://github.com/Azure/azure-sdk-for-java/issues/33229

Milestone 5 -- Dec 23
Support native images
https://github.com/Azure/azure-sdk-for-java/issues/33230

Update:
The redis passwordless service team is still in private preview, so whether to create the reference doc in current milestone still need to confirm.

Update:

Private github repo with multiple servers demo


text:
API Review Rev 5 azure-storage-common - AccountSasPermission

https://apiview.azurewebsites.net/Assemblies/Review/afc5edc77bc34796abe232abcd00df9c
Implementing changes suggested by this API review for the class
AccountSasPermission in azure-storage-common module

I will also take of changes in AccountSasService  in this review

PR: https://github.com/Azure/azure-sdk-for-java/pull/5931


text:
Fix CVE-2022-22963

As title, FYI:https://github.com/Azure/azure-sdk-for-java/issues/28179
When upgrading to spring-cloud:2021.0.2, drop this change

API change check for com.azure.spring:spring-cloud-azure-stream-binder-servicebus-core
API changes are not detected in this pull request for com.azure.spring:spring-cloud-azure-stream-binder-servicebus-core

API change check for com.azure.spring:spring-cloud-azure-stream-binder-eventhubs-core
API changes are not detected in this pull request for com.azure.spring:spring-cloud-azure-stream-binder-eventhubs-core

/azp run java - spring - tests

authors: Netyyyy azure-sdk saragluna


text:
Add azure-core Dependency to Perf Test Libraries

Description
Adds azure-core and azure-core-http-netty as a dependency to all performance test libraries. This allows for the perf automation framework to more easily configure which version of azure-core is resolved to enable testing previously released version against what is in active development. This pattern is also follow what the SDKs do themselves with listing azure-core and azure-core-http-netty as direct dependencies to ensure the best possible Maven dependency resolution.
All SDK Contribution checklist:

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

General Guidelines and Best Practices

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

Testing Guidelines

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

/check-enforcer override


text:
ServiceBus: CheckStyle Part 1, Convert tabs to space and add license titles

This PR contains:
1, Convert tabs to space
2, Add license titles
3. A few of other checkstyles:
Bracket after if instead of a new line for the bracket
Issue: ServiceBus: CheckStyle #3513

Can one of the admins verify this patch?

authors: azuresdkci mssfang


text:
Migrate azure-maps-routes to azure-json

Description
Migrate azure-maps-render to azure-json.
All SDK Contribution checklist:

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

General Guidelines and Best Practices

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

Testing Guidelines

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

/check-enforcer override


text:
mgmt, update test on machinelearning

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

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

General Guidelines and Best Practices

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

Testing Guidelines

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

/azp run java - machinelearning - mgmt - tests


text:
Missing from Base URL fix

https://github.com/Azure/autorest/pull/1271

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

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@pomortaz

authors: azurecla jianghaolu


text:
[tables] Failing build:samples scripts

Sample Quality Effort
This issue was created because one or more packages in the tables service directory had failing build:samples NPM scripts, and I determined that the existing script was broken and could not work, or would take extra effort to repair. #12715 (Build Samples in PR CI) will replace the broken script with a placeholder that simply executes echo Skipped..
The packages in question are:

@azure/data-tables

Usually, these errors were caused by faulty assumptions, such as:

a script that executes cd samples && tsc -p ., but with no tsconfig.json or other required files in the samples folder
use of old samples scripts that no longer exist
use of new samples scripts (dev-tool) without a correct samples folder layout (e.g. missing typescript subfolder)

What do I do about this?

If the package is not customer-facing, and there are not intended to be any samples in the package (such as internal code-sharing packages): leave a comment and close this issue.
If there are currently no samples, but the package is customer facing and you intend to add samples eventually: create a tracking issue for samples if one does not exist already and close this issue.
If there are samples, and they should build, but the current scripts are not correct, either:
a. Create an issue to fix the errors and wait until #12715 is merged, then incorporate your changes.
b. Work with me to incorporate the necessary changes into #12715.
If you believe this is an error, that the package is correctly configured, and that the script should work: leave a review with a request for changes on #12715 describing how to run the samples, so that we can reconcile the build scripts with the packages' sample programs.

Fixed in #12715

repo: Azure/azure-sdk-for-js


text:
[AutoPR containerregistry/resource-manager] [ACR] Add Readonly RunErrorMessage to RunProperties

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

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


text:
Use GH aliases

updated according to the guidance

/check-enforcer override


text:
Post release automated changes for storage releases

Post release automated changes for azure-storage-blob

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


text:
[QUERY] How do step through the SDK code in Visual Studio when debugging?

I've looked over issues #6239 and #9757 but I'm unable to figure out how to step through the project source in VS (in my case, for Azure.Storage.Blobs.dll specifically). It looks like the published symbols don't have source information (see below). Am I using the wrong symbol server? Or is this level of symbols info just not available?
Any guidance on how to step through the project source without needing to enlist and build the SDK locally would be appreciated. (FYI: I'm using the Azure.Storage.Blobs NuGet package 12.9.1).

Output in VS from fetching the symbols below:
SYMSRV:  HTTPGET: /download/symbols/Azure.Storage.Blobs.pdb/4A120B30DB51487DA8F54A28C1C4B656ffffffff/Azure.Storage.Blobs.pdb
SYMSRV:  HttpQueryInfo: 801900c8 - HTTP_STATUS_OK
SYMSRV:  Azure.Storage.Blobs.pdb from https://msdl.microsoft.com/download/symbols: 297868 bytes
SYMSRV:  PATH: C:\symbols\Azure.Storage.Blobs.pdb\4A120B30DB51487DA8F54A28C1C4B656ffffffff\Azure.Storage.Blobs.pdb
SYMSRV:  RESULT: 0x00000000
https://msdl.microsoft.com/download/symbols: Symbols downloaded from symbol server.
C:\symbols\Azure.Storage.Blobs.pdb\4A120B30DB51487DA8F54A28C1C4B656ffffffff\Azure.Storage.Blobs.pdb: Symbols loaded.

@weshaggard:  Since you were involved in the efforts around source link, would you mind offering your thoughts on this?

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

I am able to get the symbols loaded for Azure.Storage.Blobs.dll. And it looks like you have them also, Please make sure you did the following.

Ensure you checked the symbols servers in Tools → Options → Debugging → Symbols → Microsoft Symbols Server
Ensure that Just My Code is not checked Tools → Options → Debugging → General → Enable Just My Code

It does look like you have 1 and 2 properly setup.

You can try clearing the SymbolsCache then trying again.
Also have a look at the Symbol Load Infromation Write click ont he dll in the module and click Symbol Load Information, thats should provide more information on what going on.

I did all that. The last part of my post shows the symbol load information and details of them being fetch from the symbol servers - complete with URL and file UUID.

Can you check to make sure sourcelink is checked.
Tools → Options → Debugging → General → Enable Source Link Support

authors: billti chidozieononiwu jsquire

repo: Azure/azure-sdk-for-net


text:
client.WebApps.GetAuthSettingsSlotWithHttpMessagesAsync returns null body

It seems that GetAuthSettingsSlotWithHttpMessagesAsync always returns a body which is null.
Code used:
       var currentSettings = await client.WebApps.GetAuthSettingsSlotWithHttpMessagesAsync(
                resourceGroup.Name,
                Name,
                stagingSlotName,
                null,
                cancel
            );
            var body = currentSettings?.Body;
            if (body != null)
            {
                ...

@fbertilsson can you provide the following information, also can you confirm if the status code 200 when you get the null body?

Version of the SDK you are using
Fiddler trace that shows the request and response

I have not seen any change in the swagger, the response is a complex object and it should return body with the response.
@ahmedelnably for visibility

I'm using Microsoft.Azure.Management.Websites version 1.6.0-preview

authors: fbertilsson shahabhijeet


text:
Fluent SDK - Query deployment failure reason

Currently resourceManager.Deployments.GetByResourceGroup(...)
returns IDeployment
In case a deployment fails, I don't see a way to find out failure reason to log it

@anuchandy is there a better answer to this than "by design"?

This issue was moved to Azure/azure-libraries-for-net#39

authors: abhi1509 hovsepm martinsawicki


text:
MaxSizeInMegabytes is ignored and always sets the queue to 16GB

It seems that no matter what value to provide to the MaxSizeInMegabytes property, the queue is always created with the max size of 16GB, is this expected?
The following simple code to create a queue highlights this problem.
using (var managementClient = new ServiceBusManagementClient(new TokenCredentials(accessToken)))
{
    managementClient.SubscriptionId = "MySubsciptionId";
    var queueParams = new SBQueue
    {
      EnablePartitioning = true,  // <-- Only when this is true
      MaxSizeInMegabytes = 2048  // <-- Get ignored, even if not setting the property at all, the default is 16GB not 1GB as stipulated by the documentation.
    };

    await managementClient.Queues.CreateOrUpdateAsync(Constants.ResourceGroupName, Constants.NamespaceName, "TwoGBQueue", queueParams);
}

The documentation claims the default it 1GB, but the queue is always created as a 16GB queue.

I've figured out that this only happens when you have EnablePartitioning switched on. Setting that to false honors the max size setting. Would certainly help having the documentation highlight this to avoid confusion.

@brutaldev - thanks for bringing this to our attention. This has already been documented here.
I'm closing the issue for now, but please feel free to reopen if you still have questions.

authors: axisc brutaldev


text:
Log Diagnostic Scope Start/Stop/Fail

We've got great operation names for diagnostic scopes that would be nice to associate with our HTTP logs.  We should add additional events to our AzureCoreEventSource to expose this info.
See #9274 for additional discussion.

Moving to backlog for now.

We didn't have many customer asks for this and distributed tracing provides similar functionality.

authors: pakrym tg-msft


text:
Added IKeyVaultClient

Hey
I've created an interface for keyvaultclient class. This done in order to improve testability of classes that depended on keyvaultclient.
Thanks
Omer

Can one of the admins verify this patch?

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

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.azure.com.

TTYL, AZPRBOT;

@azuresdkci test this please

@omerlh, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, AZPRBOT;

Thanks @omerlh for your contribution. The interface will change with the next major version of the Key Vault SDK and we don’t want any dependency to this interface. I will make sure the next major version of the SDK will have an IKeyVaultClient interface.

authors: azurecla azuresdkci hovsepm omerlh pomortaz


text:
Address review comment to fix version to be 6.1.0-preview

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

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

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

[ ] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[ ] I have read the contribution guidelines.
[ ] The pull request does not introduce breaking changes.

General Guidelines and Best Practices

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

Testing Guidelines

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

SDK Generation Guidelines

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

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

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

Management plane SDK Troubleshooting

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

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

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

This is addressing offline comments related to PR -> https://github.com/Azure/azure-sdk-for-net/pull/18872


text:
SDK changes for Vmss Flex deleteOption

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.

/azp run net - mgmt - ci

/azp run net - mgmt - ci

/azp run net - mgmt - ci

authors: grizzlytheodore kimberlyyipc


text:
docs(dpg): update ProtocolMethods.md

update ProtocolMethods.md to be more aligned with existing PetsStoreClient and Pet.
remove section regarding RequestContext since it's a duplicate, and add links to overall readme and sample index.
remove unused id property from Pet model
add a code snippet directive in unit test, for sample contents
fix parameter names in PetStoreClient

part of #26454
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.

This PR focuses on cleaning up some obvious errors in the ProtocolMethods.md.
We still have a fundamental problem to solve: PetStoreClient is not generated, which will be resolved in #28315

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

authors: archerzz azure-sdk


text:
[Event Hubs] Change stress references

Summary
The focus of these changes is to temporarily change the stress project reference to a package reference for the Event Hubs core package, so that the processor and stress project both hold the same reference.  I believe this is needed to resolve temporary restore conflicts.
References and Resources

Build failures with restore (Microsoft Internal)

/azp run net - eventhub - tests

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

authors: azure-sdk jsquire


text:
[Storage] Added ResumeTransferAsync to TransferManager

Added TransferManager.ResumeTransferAsync which will allow to resume transfers that are in a resumable state
Added tests

Follow up

Do we need to remove the TransferOptions.ResumeFromCheckpointId so customers would use this API over the one in the options bag?

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

authors: amnguye azure-sdk


text:
Regenerate SDKs with a missing parameter in AddFaceFromStream operation in FaceList

Regenerate SDKs adding a missing parameter.

@shahabhijeet the latest version of Autorest as shown here is 4215?
https://www.npmjs.com/package/autorest

Not sure what the error from CI is all about though.


text:
Failed Autorest Regen Preview to 3.0.0-alpha.20240208.3 by Chun Yu from refs/pull/4212/head

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

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


text:
Autorest Regen Preview to 3.0.0-alpha.20240311.6 by Alexander Sher from refs/pull/4384/head

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

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


text:
Export APIs for missing RPs

API files are not up-to-date due to https://github.com/Azure/azure-sdk-for-net/pull/43563, not all CI got to run during the merge.
This is blocking https://github.com/Azure/azure-sdk-for-net/pull/43635

/azp run

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


text:
Increment version for resourcemanager releases

Increment package version after release of Azure.ResourceManager

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

/check-enforcer override

Failures are unrelated to these changes; Merging.


text:
[docs] AppConfig README

Fix links in intro
Bulleted feature/operation list in intro and simplify to adhere more closely to README template format
Markdownlint accommodations (mostly spacing)
Remove /en-us/ locale identifier from docs.microsoft.com URLs to allow browser redirect in non-US locales

@scbedd Hey Scott, is this something you can review?


text:
Add ability to exclude api versions while playing back sql tests

This will help us introduce new api versions for existing apis without the need to re-record tests.
Should help with developer productivity.

@johnpaulkee This PR has thousands of commits going back to 2016. Please rebase your changes onto master.

Will do :)

I'll resubmit PR.

authors: brjohnstmsft johnpaulkee


text:
'HyperDriveStep' requires 'ScriptRunConfig' to have attribute called 'data_references'

Package Name: azureml.train.hyperdrive.HyperDriveConfig()
Package Version: 1.0.1b6.pos1
Operating System: Windows 10
Python Version: 3.8.5

Describe the bug
when I create a pipeline step for hyperdrive and specify the run_config parameter as a ScriptRunConfig object, initialization of HyperDriveStep fails because ScriptRunConfig has no attribute 'data_references'.
To Reproduce
Steps to reproduce the behavior:

create a ScriptRunConfig object with a training script

run_config = ScriptRunConfig( source_directory=source_directory, script="train.py",
environment= Environment.get(ws, name="xgb-hp"),
    compute_target= compute_cluster)

create a HyperdriveConfig object with this ScriptRunConfig.

hyperdrive_config = HyperDriveConfig(  run_config=run_config,
    hyperparameter_sampling=bayesian_sampling,
    primary_metric_name='test-mae-mean',
    primary_metric_goal=PrimaryMetricGoal.MINIMIZE,
    max_total_runs=60,
    max_concurrent_runs=3
    )

try to create a HyperDriveStep object of a pipeline with this HyperdriveConfig

hyperdrive_step = HyperDriveStep(
        name='storeys:hyperdrive',
        hyperdrive_config=hyperdrive_config,
        estimator_entry_script_arguments=[],
        inputs=[train_dataset.as_input('train')],
        outputs=[params_dataset],
    )

Expected behavior
A clear and concise description of what you expected to happen.
HyperDriveStep should hot ask ScriptRunConfig for this atribute
Screenshots
If applicable, add screenshots to help explain your problem.
this is the Error stack:
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-57-26fcafea004b> in <module>
      1 # creates the hyperdirve pipeleine step
----> 2 hyperdrive_step = HyperDriveStep(
      3         name='storeys:hyperdrive',
      4         hyperdrive_config=hyperdrive_config,
      5         estimator_entry_script_arguments=[],

~\.conda\envs\AML-prep-xgb\lib\site-packages\azureml\pipeline\steps\hyper_drive_step.py in __init__(self, name, hyperdrive_config, estimator_entry_script_arguments, inputs, outputs, metrics_output, allow_reuse, version)
    188         if run_config.arguments:
    189             raise ValueError('arguments in run_config should not be provided. Please use arguments in the step')
--> 190         if run_config.data_references:
    191             raise ValueError('data_references in run_config should not be provided. Please use inputs in the step')
    192

AttributeError: 'ScriptRunConfig' object has no attribute 'data_references'`

Additional context
Add any other context about the problem here.

Hi,
I have same problem. How did you solve it?

@masgra
Hi,
I have  same problem. How did you solve it?

Should be fixed with the newest version of AML SDK. If you can't updat, you are stuck with using Estimator

Should be fixed with the newest version of AML SDK. If you can't update, you are stuck with using Estimator

Yes. It works now. Thanks

authors: CakmakMuhammet masgra

repo: Azure/azure-sdk-for-python


text:
azure-mgmt-postgresqlflexibleservers 1.1.0b1 : Why is list_by_server for tuning options failing

azure-mgmt-postgresqlflexibleservers 1.1.0b1
Windows 11
https://pypi.org/project/azure-mgmt-postgresqlflexibleservers/1.1.0b1/
Describe the bug
Want to understand why trying to use list_by_server for tuning options resources, generates error during deserialization
The command failed with an unexpected error. Here is the traceback:
Unable to deserialize to object: type
Traceback (most recent call last):
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\mgmt\postgresqlflexibleservers_serialization.py", line 1463, in _deserialize
found_value = key_extractor(attr, attr_desc, data)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\mgmt\postgresqlflexibleservers_serialization.py", line 1211, in rest_key_extractor
return working_data.get(key)
AttributeError: 'list' object has no attribute 'get'
To Reproduce
Following sample from file
client = PostgreSQLManagementClient(
credential=DefaultAzureCredential(),
subscription_id="ffffffff-ffff-ffff-ffff-ffffffffffff",
)
response = client.tuning_options.list_by_server(
    resource_group_name="testrg",
    server_name="testserver",
)

Expected behavior
Expected list to be deserialized and returned
Screenshots
The command failed with an unexpected error. Here is the traceback:
Unable to deserialize to object: type
Traceback (most recent call last):
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\mgmt\postgresqlflexibleservers_serialization.py", line 1463, in _deserialize
found_value = key_extractor(attr, attr_desc, data)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\mgmt\postgresqlflexibleservers_serialization.py", line 1211, in rest_key_extractor
return working_data.get(key)
AttributeError: 'list' object has no attribute 'get'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\knack\cli.py", line 233, in invoke
cmd_result = self.invocation.execute(args)
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init_.py", line 666, in execute
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init_.py", line 666, in execute
raise ex
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init_.py", line 733, in _run_jobs_serially
results.append(self.run_job(expanded_arg, cmd_copy))
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init.py", line 716, in run_job
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init.py", line 733, in _run_jobs_serially
results.append(self.run_job(expanded_arg, cmd_copy))
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init.py", line 716, in _run_job
results.append(self.run_job(expanded_arg, cmd_copy))
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init.py", line 716, in run_job
File "c:\users\nasc\azurecli\azure-cli\src\azure-cli-core\azure\cli\core\commands_init.py", line 716, in _run_job
result = list(result)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\core\paging.py", line 123, in next
result = list(result)
result = list(result)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\core\paging.py", line 123, in next
return next(self._page_iterator)
result = list(result)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\core\paging.py", line 123, in next
return next(self._page_iterator)
return next(self._page_iterator)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\core\paging.py", line 83, in next
self.continuation_token, self._current_page = self._extract_data(self._response)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\mgmt\postgresqlflexibleservers\operations_tuning_options_operations.py", line 406, in extract_data
deserialized = self._deserialize("TuningOptionsListResult", pipeline_response)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\mgmt\postgresqlflexibleservers_serialization.py", line 1408, in call
return self._deserialize(target_obj, data)
File "C:\Users\nasc\azureCLI\azure-cli\env\lib\site-packages\azure\mgmt\postgresqlflexibleservers_serialization.py", line 1478, in _deserialize
raise DeserializationError(msg) from err
azure.core.exceptions.DeserializationError: Unable to deserialize to object: type
Additional context
I want to make sure I understand the error, it is saying it cannot reserialize due to the tuning option resource not having a get call, but I see it part of the file?
Error in code
deserialize("TuningOptionsListResult"
Get call
get call for tuning option

got it

Hi @nasc17, in here, you defined the TuningOptionsListResult as an iterable object, which means the service would return an iterator instance as response.
For example, by run this sample, the response is like:
{"value":[{"sku":{"name":"Standard_B1ms","tier":"Burstable"},"systemData":{"createdAt":"2024-11-13T03:19:37.3429536Z"},"properties":{"replica":{"role":"Primary","capacity":5},"storage":{"type":"","iops":120,"tier":"P4","storageSizeGB":32,"autoGrow":"Disabled"},"network":{"publicNetworkAccess":"Enabled"},"privateEndpointConnections":[],"dataEncryption":{"type":"SystemManaged"},"authConfig":{"activeDirectoryAuth":"Disabled","passwordAuth":"Enabled"},"fullyQualifiedDomainName":"chenxiserver.postgres.database.azure.com","version":"16","minorVersion":"4","administratorLogin":"root1","state":"Ready","availabilityZone":"1","backup":{"backupRetentionDays":7,"geoRedundantBackup":"Disabled","earliestRestoreDate":"2024-11-13T03:26:16.7958974+00:00"},"highAvailability":{"mode":"Disabled","state":"NotEnabled"},"maintenanceWindow":{"customWindow":"Disabled","dayOfWeek":0,"startHour":0,"startMinute":0},"replicationRole":"Primary","replicaCapacity":5},"location":"East US","tags":{},"id":"/subscriptions/subscription/resourceGroups/resourceGroup/providers/Microsoft.DBforPostgreSQL/flexibleServers/chenxiserver","name":"chenxiserver","type":"Microsoft.DBforPostgreSQL/flexibleServers"}]}

Yet by running the code you mentioned, the service actually gives a response as a list, which doesn't match the type of TuningOptionsListResult, so the deserialization error occurs:
[{"properties":{},"id":"/subscriptions/subscription/resourceGroups/resourceGroup/providers/Microsoft.DBforPostgreSQL/flexibleServers/chenxiserver/tuningOptions/index","name":"index","type":"Microsoft.DBforPostgreSQL/flexibleServers/tuningOptions"}]

And this error AttributeError: 'list' object has no attribute 'get' occurs just because we supposed to have an object but here we got a list. The get here is actually Object.get, not TuningOptionsOperations.get.
source code: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/postgresqlflexibleservers/azure-mgmt-postgresqlflexibleservers/azure/mgmt/postgresqlflexibleservers/_serialization.py#L1211

Thank you for helping me to determine this was a type mismatch defined from swagger. Will work to update for new release


text:
Release Cosmos Track 2 Library Preview 4 for Python

[x] 	Implement request timeout parameters
o	Avoid conflicts with “request timeout” – e.g. operation timeout
o	Rename request timeout to socket timeout
[x]	Revisit retry policy as pipeline policy
o	Still under discussion
o	Transport level-retry
[x]	Accept transport object in constructor kwargs

Shipped

authors: annatisch mayurid


text:
Add azurestackhci ci.yml for pipeline generation.

This PR adds a pipeline for azurestackhci. This is needed for the release/v3 branch and isn't present on master. However we are going to take advantage of pipeline generation from master to correctly configure the pipeline rather than creating it manually. We'll then tweak the settings of the automatically generated pipeline so we don't create nightly build failure noise from master.

@Azure/azure-sdk-eng merging now since this won't pass (for a known reason).


text:
[AutoPR] logic/resource-manager

Created to accumulate context: logic/resource-manager

(message created by the CI based on PR content)

@AutorestCI rebase

Rebase done and pushed to the branch

@AutorestCI rebuild https://github.com/Azure/azure-rest-api-specs/blob/master/specification/logic/resource-manager/readme.md

Working on generating https://github.com/azure/azure-rest-api-specs/blob/master/specification/logic/resource-manager/readme.md for you!!!

Build SDK finished and cleaned

Codecov Report

Merging #2524 into master will decrease coverage by 0.19%.
The diff coverage is 41.49%.

@@            Coverage Diff            @@
##           master    #2524     +/-   ##
=========================================
- Coverage   56.01%   55.82%   -0.2%
=========================================
  Files        6850     7010    +160
  Lines      146483   149027   +2544
=========================================
+ Hits        82058    83188   +1130
- Misses      64425    65839   +1414

Impacted Files
Coverage Δ

...ic/models/integration_account_certificate_paged.py
80% <ø> (ø)
:arrow_up:

...ogic/azure/mgmt/logic/models/workflow_run_paged.py
80% <ø> (ø)
:arrow_up:

.../azure/mgmt/logic/models/workflow_trigger_paged.py
80% <ø> (ø)
:arrow_up:

azure-mgmt-logic/azure/mgmt/logic/__init__.py
100% <ø> (ø)
:arrow_up:

...mt-logic/azure/mgmt/logic/models/workflow_paged.py
80% <ø> (ø)
:arrow_up:

...ogic/models/integration_account_agreement_paged.py
80% <ø> (ø)
:arrow_up:

...t/logic/models/integration_account_schema_paged.py
80% <ø> (ø)
:arrow_up:

.../logic/models/integration_account_session_paged.py
80% <ø> (ø)
:arrow_up:

...mgmt/logic/models/integration_account_map_paged.py
80% <ø> (ø)
:arrow_up:

...ure/mgmt/logic/models/integration_account_paged.py
80% <ø> (ø)
:arrow_up:

... and 437 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 913ef9a...c4ea630. Read the comment docs.

authors: AutorestCI codecov-io lmazuel


text:
[Storage] [Typing] [File Share] Resolved _share_client.py and _share_client_async.py mypy errors

🧙

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


text:
Evaluate api missing input fix

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

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

General Guidelines and Best Practices

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

Testing Guidelines

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

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

authors: azure-sdk diondrapeck


text:
Re-enable BuildTargetingString for mgmt release unblockers

@msyyc this is bringing back the ability to filter the build down even farther, to deal with instances when data plane packages are failing, and you need to release a mgmt package.
Proving build with buildtargetingstring set to azure-mgmt-cosmosdb

Looks good to me.

authors: msyyc scbedd


text:
Certificates: admin_details rename

fixes #8718

Can one of the admins verify this patch?


text:
[AutoPR compute/resource-manager] Swagger improvements: Add example to Generalize API

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

(message created by the CI based on PR content)

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


text:
Add setters macro

This might not be worth it, but I decided to play around with creating a macro_rules macro for declaring setters in request builders. This reduces the amount of repetition. I only implemented this for a few builders but you should get a sense of what this will look like across all the builders.
Setters are now declared like this:
setters! {
  user_agent: &'a str => Some(UserAgent::new(user_agent)),
  activity_id: &'a str => Some(ActivityId::new(activity_id)),
  consistency_level: ConsistencyLevel => Some(consistency_level),
}

I also removed the private getters since they're not really needed.

@MindFlavor Thoughts on this?

I really like it, it makes the code much more lean and manageable. I also agree that getters are not needed in request builders, further simplifying the code.
Great work 🥇 !

@MindFlavor this is ready for review!

authors: MindFlavor rylev

repo: Azure/azure-sdk-for-rust


text:
Translate complete 'docs/python/implementation.md' into korean

related issue: https://github.com/Azure/azure-sdk-korean/issues/178
Change the translation of the word bookkeeping: 부기 -> 연결별 관리 데이터(bookkeeping)

Reference: https://github.com/Azure/azure-sdk-korean/pull/191#discussion_r1336677770

Edit sidebar via complete translating docs/python/implementation.md page.

Appreciate this PR - looks great thank you!!

authors: bnbong ianychoi-dev

repo: Azure/azure-sdk-korean


text:
ClientModel: Add an analyzer to ensure that un-branded clients' client options types inherit from ClientPipelineOptions instead of using it directly

We will need to add an analyzer to ensure that un-branded clients' client options types inherit from ClientPipelineOptions instead of using it directly.  This is different from Azure.Core-based clients where the fact that the ClientOptions type is abstract ensures that clients' options type must have a subtype.

@pallavit, it is important to track this with other ClientModel deliverables to make sure we have it before we start shipping unbranded clients.  Do you know if there is a way to update the milestones for this issue so it will track with others?  If not, should I create a parallel issue in azure-sdk-for-net to include in the ClientModel backlog?

repo: Azure/azure-sdk-tools


text:
Standardize Prettier configuration

The configuration files for tool Prettier should be standardized across all repos.  Proposal:

Use a single .prettierrc file at the repo root
All config files should be named .prettierrc and use the YAML format (no .prettierrc.json)
No .prettierrc files in sub-folders unless there's a good reason.  We want to be as consistent across folders as possible.
Use the "override" feature to specify different formats for different files (e.g. double-quotes for *.yml but single-quotes for *.js)

@chidozieononiwu, this issue is over a year old at this point.  It's definitely tools related, but @weshaggard and I suspect there isn't any work left to do here.  Please take a look and close if it's already done.

So far prettier has not been used on any other repo other than JS. @mikeharder do you still think ther is a need to make the configuration cross repo. Also right now the json style is still used, I can go ahead and do the work to convert to the yml format if that is still useful.

I think it's fine to close this out until there is more demand for it.

authors: chidozieononiwu kurtzeborn mikeharder

repo: Azure/azure-sdk


text:
rust pod options

Declare concrete parameter types for Rust
Use PODs instead of builders for Rust options

Need to rebase on main after #8186 is merged.


text:
Function Execution Timeouts

Need to figure out the story for Function execution timeouts, both to ensure that functions/processes that never terminate (e.g. while(true) cases) don't run forever. This might take the form of a default timeout that can be user configured per function via config. Note that the core WebJobs SDK has a TimeoutAttribute which we could leverage.
E.g. we might set a safety default timeout of something like 5 minutes or so to prevent runaway executions, but allow people to raise that for long running batch scenarios.
Similarly, we need to handle process timeouts for functions that are spawned exes (e.g. BAT functions)

RC justification: Needed to help control billing costs

We might be able to leverage the SDK TimeoutAttribute for this. See example here. We could just expose a new function metadata property that maps to this.

As part of this, for Node, we should also bring in the the tripwire module to catch while(true) errors (just like we did in Zumo).

Hi folks, I have a couple of questions on this issue:
I have a Timer Trigger - PowerShell Azure Function that runs each week day at the same hour, my run.ps1 execute a .exe that makes a "heavy work", running by ~20 minutes on each execution. The issue is that when the function is triggered it never completes the process, I think it is a "timeout" on the Azure Function "pipeline". After a while the Log Console prints out: No new trace in the past {x} min(s).  but none of my logs (Write-Output)
But when I execute my .exe from the Kudu Console the work run and finish as expected.
My two questions are: Is there a "timeout" on the Azure Function "pipeline"? How to "skip/configure" this timeout to run my "heavy work" .exe?
Thanks

This is a bigger work item and won't be done by Iteration 20.

Any update on weather timeouts on azure functions are configurable now? thanks!

This work is in progress with an open PR (#604).

great thanks! Any ETA on having it on prod?

This is now committed with #604 but not yet in prod. The behavior is as follows:

By default, every function has a timeout of 5 minutes, which is also the maximum timeout. The minimum value is 1 second.
When a function timeout is hit, the function application is shut down to prevent runaway functions from executing infinitely. When a new trigger fires, the site will come back up, which may happen immediately. This means that functions that are operating normally may also be shut down if another function in the function application has timed out.
For C# functions, you can use a CancellationToken parameter in your function. That token will be canceled whenever a timeout occurs (or any host shutdown is imminent). You can then exit your function gracefully.
Function logs will indicate that a function has exited due to a timeout.
The timeout can be adjusted in the host.json file by specifying a TimeSpan value in the timeout property. This will apply to all functions. For example, this sets the timeout to 1 minute:

{
    "timeout" : "00:01:00"
}

@brettsam Do you know if the WEBJOBS_IDLE_TIMEOUT have some effect on Azure Functions timeouts?

@brettsam what's the thinking behind having a maximum timeout of 5 minutes? Would there be a way of renewing the timeout?
We're using functions that may take longer to execute and would be difficult to split over multiple calls. As default that's fine, but it's a shame to exclude using this for potentially long running computation. The Azure Functions has been really promising for deploying bits of scientific modelling code and easily adding an HTTP endpoint.

The maximum of 5 minutes will only apply in our Dynamic SKU. If you run in one the classic paid SKUs (Basic/Standard) with AlwaysOn enabled there will be no limit.
@nicolocodev No, WEBJOBS_IDLE_TIMEOUT does not apply to Functions.

I am in the same boat as @cgravill.  We use PowerShell Azure Functions to upgrade/downgrade the service level for SQL Azure databases on a daily schedule.  This single operation usually takes around 15 minutes and the timeout now prevents the function from publishing the results when the operation completes.  Is Azure Functions no longer a viable solution for simple uni-task operations like this?  We don't need the job to be always on to perform these simple tasks two times a day.  It seems that if Functions doesn't even have a timeout large enough to perform autonomous ARM operations that perhaps the timeout is too small?  @brettsam am I thinking about this wrong?  I have not worked with traditional WebJobs yet, so perhaps that is a better alternative.  But so far everything I've read about Functions matched up nicely with the problem I was trying to solve.

Reopening so we can discuss options.

Same here, we need to run several long (hours) database related tasks a few times per year, having to manually manage a VM for this would be a waste.
The Azure Functions Overview even mentions this specific scenario!

Consider Functions for tasks like image or order processing, file maintenance, long-running tasks that you want to run in a background thread, or for any tasks that you want to run on a schedule.

If your goal is to run a PowerShell script that runs on a schedule and manages your Azure resources, you should look at Azure Automation. It's exactly what it's for, and it likely a better fit than Azure Functions for such task.

One of our long running tasks is scheduled but others may be triggered by an HTTP request or something else.  Is Azure Functions no longer intended to support long running tasks?  It seems that if the purpose of this change was to prevent tasks from getting stuck in a loop, perhaps a good approach would be:

Default timeout of 5 minutes.
Default timeout can still be overridden in host.json.  This max can still be 5 minutes.
Allow individual functions to be configured to override the default (perhaps with a max on the order of hours or one day?).

This would allow function authors to set a reasonable timeout for that particular task without raising the limit for all functions.
Of course, if the intent of Functions is now scoped to tasks <= 5 minutes, then that is good to know and we will just need to look into migrating our long running tasks elsewhere (Azure Automation, etc.).

Thanks for the feedback. A little more background:
The reason we timeout at 5 minutes with the Dynamic plan is because under the Dynamic plan, the VM that is hosting your function will shut down (roughly) 5 minutes after the last trigger fired. Enforcing the timeout like we're doing today is a way to provide a consistent experience with logging that explains why the function stopped running. Before this, you would see functions simply disappear mid-invocation without any indication of why. We're evaluating improvements in this area and will update when we have more concrete details.
Long-running functions that cannot be decomposed down into smaller chunks will run into issues running in the Dynamic plan currently. However, there are often solutions for breaking down single long-running functions into smaller, quicker functions. For example, if you have a function that kicks off a long operation elsewhere, then polls for completion, could you get an 'operationId' from that operation, then put it in a Service Bus scheduled message (or even in a Queue message with an invisibility timeout), and have a second 'CheckStatus' function that reads those messages and polls for completion?
It may be interesting to capture some of the long-running scenarios here and see if we can establish some patterns. Feel free to chime in here with your long-running scenarios if you have them. That'll help drive future improvements in this area.

That seems reasonable, however we have a bunch of queries copying rows from one Azure SQL database to another, then deleting those rows from the first database. We could split each insert/delete up into separate function calls but even then some of them will run for multiple hours maybe once or twice per year.
I don't believe it's possible to run a query, close the connection and return later to check on the progress either.
Moving this to an app service would mean we'd have to juggle around with scaling between free tier/paid tier and deployments, because it also doesn't seem to be possible to stop and deallocate them like you can with a regular VM and paying year round for something that runs for a couple of days seems like a huge waste. This is one of the reasons we're moving away from the split-merge service.
Would love to hear suggestions on a better approach for this!

Moving back to triage since this closed issue was reopened to discuss options.

We have a similar scenario in which we run one or two long-running jobs (couple hours) once a week which we were hoping to use Azure Functions for on the Dynamic plan but the 5-minute cap is a blocker.

Please add any scenarios you might have to the top level issue here (https://github.com/Azure/Azure-Functions/issues/75).

If platform work is done to enable functions to run for longer than 5 minutes (tracked by https://github.com/Azure/Azure-Functions/issues/75) then we'll need updates here to relax our validation. Otherwise there is no further work here.

I am not hitting this time out in my implementation. I created my function to run a task that takes longer than 5 mins buy using a Task for my logic. The function returns right away obviously since the logic is now async. My async task runs to completion outside the 5 min timeout. Try this and see for yourself.
`DateTime d = DateTime.Now;
Task t = new Task(() =>
{
log.Info("Doing long task");
for (int cnt = 0; cnt < 100; cnt++)
{
log.Info(DateTime.Now.Subtract(d).ToString());
System.Threading.Thread.Sleep(10000);
}
});
t.Start();'
I am currently running them on a consumption plan for more than 5 mins, as per my post. There is a timeout, but it’s not on execution time obviously since I am running them longer than 5 mins. The time out is in the calling mechanism that executes the function. If you make it async, the caller returns and the function continues to execute. It is a common practice to put long running tasks on a separate thread/process than the calling thread/process. Keeping the orchestration layer of the function platform from blocking for long periods of time just makes sense. You should not block the calling layer for long running functions as it will seriously degrade the platform.
I wasn't trying to bypass the 5 min timeout, but rather trying to develop with good disciplines. I wanted an async function. I learned about the 'timeout' later. No one should be running long running functions synchronously anyway. Also, people should be aware of how to make async functions regardless of timeouts.
The interwebs can really be a silly place sometimes. I think people are getting so used to cut and pasting code, they are forgetting the basics.
PS. Please add your constraints to this Azure doc:
https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits#app-service-limits
William Wallace

Correct - if you spin off an async task outside of the function execution (which we're monitoring), if your Function App stays alive due to other traffic, it won't be limited. The limit we have in place is all about making things predictable for users in our consumption plan. The underlying infrastructure will currently shut down the VM instance (as described elsewhere above) if no new triggers/invocations have happened in 5 minutes. That being the case, you can't really run reliably over 5 minutes.
However above we also link to https://github.com/Azure/Azure-Functions/issues/75, where we discuss making lower level changes allowing us to relax this limit.

If I am running async functions, can you guarantee at least 5 mins? I am more than a little surprised that I have not seen any postings or talk on async implementations. What is your confidence level in async execution of a function? Will it possibly mess with your orchestration logic negatively if you cannot detect workloads outside synchronized calls?

Apart from my questions and experiences with creating async functions and their interactions with this limit, for long running processes, I have maintained the state for the work being done outside the function and recursively called the function with a reference to the state when its duration approaches the 5 min limit. This allowed me to optimize execution count and time. This was worth the effort since this function was used intermittently. Using parallelism within the function can also decrease execution time. This also allowed me to have some control over throttling how many and how quickly the workitems were being processed. With this type of tech, since it scales so high and quickly, you can easily create your own DDOS attack on your internal systems if you are not careful.

I'll summarize all this by saying that any work started out of band from a normal function invocation (e.g. you spin up a background task that runs after the function returns) is not guaranteed to run reliably. Our underlying infrastructure can choose to release the VM at any time in such scenarios.

@DarkNoir , async functions will have the same guarantees, as long as you're following proper patterns and returning the Task representing your async work. As @mathewc pointed out, the pattern you've shared above is not going to be reliable and is definitely not something we recommend.

Yeah, unfortunately, the async pattern I was shooting for was the ‘fire and forget’ async that does not require synchronization, ever. (A proper pattern, just possibly not supported in your implementation at this time and thus cannot be recommended.). Having to synchronize Atomic and usually idempotent units of work chaffs a bit.
Or, I am missing something and it can be done and I haven’t figured it out yet and no one has pointed out the way to achieve async azure function calls is just not how I was attempting to do it.
2 facets where in my discussions today.

The 5 min execution time limit. I was seeing runtimes outside that because there were other things keeping my vm up outside my executing code. – RESOLVED, my perception was incorrect.

I was wanting to execute functions asynchronously  (fire and forget, not wait for completion) I believe this is resolved and the answer is NOT SUPPORTED.

Is my understanding correct now? I really appreciate how much help you guys are helping me make sense of what I am seeing. I am doing this so I can share this understanding with others also.

@brettsam, related to your pattern suggestion for long running operations above:
Do I understand this szenario correctly that your described long running operation runs somewhere outside of Azure Functions and Azure Functions (AF) is used to get the status of this operation periodically via for example a message queue trigger?

AF1 starts long running operation outside of Azure Functions infrastructure
Long running operation return operationID immediately
AF1 sends message to queue which will be processed by AF2 e.g. 3 min later
AF2 processes the message after 3 min
AF2 checks long running operation status and logs the status (running, error, successful)
AF2 starts repeating process step (3) and following
AF2 notifies AF1 on success, error or status after a reached timelimit via a webhook call

Is this the way you described or did I get something wrong?

Another question:
Related to long running Azure SQL operations, are there any plans to support Azure SQL inbound triggers which notify a function on defined events (e.g. new row in table ABC was added)?

What about applying a timeout on a per function level?

@mikezks  and @niemyjski  Please open new issues or forum posts for new questions. We don't monitor closed issues.

Hi,
I have a continuous web job created using console app. I am calling external web service from the web jobs. Web service takes about 7-8 minutes to respond. Web job looses the web service connection after ~5 minutes but still keep on waiting for response until it times out after the "ReceiveTimeout" value. I am suspecting that it is the idle timeout out kicks in and drops the web service connection. Please note that the external web service is hosted on azure VM and has idle timeouts set to 30 mins.
Any inputs on this?
Regards,
Kiran Chauhan

@kchauhan-muhimbi With the current limits in place, you won't be able to work with such as web service from the consumption plan. You'll need to switch to a dedicated app service plan.

Hi Paul,
We are on Basic tier of web app, would it still not work? I think, Basic falls under dedicated app service plan. Please advice.
Thanks,
Kiran Chauhan
SharePoint Consultant
Sent from my iPhone
On 02-May-2017, at 10:07 PM, Paul Batum <notifications@github.commailto:notifications@github.com> wrote:
@kchauhan-muhimbihttps://github.com/kchauhan-muhimbi With the current limits in place, you won't be able to work with such as web service from the consumption plan. You'll need to switch to a dedicated app service plan.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-webjobs-sdk-script/issues/18#issuecomment-298689810, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYAeSddjZ5fMtmC0x5ldQuHQueTwN1vSks5r11uwgaJpZM4HYgFo.

@kchauhan-muhimbi Thanks for the clarification. I re-read your original comment. The issue you are experiencing is unrelated to this thread. This thread is about Azure Functions, and specifically the five minute execution limit when in the consumption plan.

Update on this - the default timeout value is being increased from 5 minutes to 20 minutes.

When will the increased timeout be available? When I try to increase the timeout in my host.json file to anything over 5 minutes I get the error:
We are not able to retrieve the runtime master key. Please try again later.
thanks

For anyone reading this, I am finding out that Azure Functions are incredibly fragile and unpredictable. For instance I just spent an hour researching how to debug the yellow exclamation mark response on the metrics console, and during that time the function magically started to work. Then magically fell back over 3 hours later after a simple code reformat. Most of the problems i'm having don't have to do with heavy workloads or anything. It almost seems like you need to give azure functions a couple hours to "warm up" before it starts interpreting the code correctly. Is anyone else having a similar experience?

@ttrace1995 sorry to hear you're running into issues. Would you mind opening a separate issue with more details about the issue you're seeing and the information requested on the issue template so we can identify and take a closer look at your app?

For those here looking to apply functionTimeout to Azure Functions - be aware this ONLY applies to web jobs - you have to write your own timeout logic for AF.

@alohaninja FunctionTimeout must be between 00:00:01 and 00:10:00

See: https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#consumption-plan

authors: ADringer DarkNoir Goz3rr alohaninja brettsam cgravill christopheranderson davidebbo fabiocav kchauhan-muhimbi laiello lindydonna manoharreddyporeddy mathewc mattscully mikezks nicolocodev niemyjski nkaviani paulbatum punitganshani ttrace1995

repo: Azure/azure-webjobs-sdk-script