Azure
Customize HTTP timeout / retries
Description of the new feature
It would be good if users can customize both the HTTP timeout and retries. Both seems to be fixed at the moment.
Proposed implementation details (optional)
It would be good if the implementation is aligned to Inside the Azure SDK Architecture. For instance by exposing the RetryOptions of the underlying .NET SDK.
@fawohlsc , could you explain further which case needs user to set timeout/retries? Our feeling is it is too technical to end user and it's not good approach to ask customer tune the number.
@dingmeng-xue. First of all, appreciate your prompt response.
The use case is to reduce transient errors in scheduled and long-running scripts i.e. Pester tests (e.g. fawohlsc/azure-policy-testing). My Pester tests run for 2-3 hours and I discovered transient errors due to the HTTP timeout limit of 100s being exceeded. This transient errors could be easily eliminated by changing the HTTP timeout. For now, I am forced to retry the failing Pester test.
Also for consistency reasons it makes sense to expose the possibility to change the default timeout to the end user. For instance the Azure .NET SDK allows users to change the HTTP timeout - in Azure PowerShell you cannot do this for the time being. I understand your concern that this might be too technical, but if you keep your reasonable timeout of 100s and allow users amending it when needed should cover that concern.
we will consider requirement #13520 with this together. Both plan to impact HTTP pipeline configuration.
Having this feature would be very helpful for me as well. I'm currently running into an issue where the New-AzResourceGroupDeployment command fails on a single deployment of mine. The template is quite extensive and it takes the validation steps ~2 minutes to run, which exceeds the connection timeout, so the resource group deployment never goes into submission. I've verified in the Azure Activity Logs that the deployment is received and successfully validates. In my local console, I get the following chain of exceptions
11:26:38 AM - Error: Code=; Message=The request was canceled due to the configured
HttpClient.Timeout of 100 seconds elapsing.
, 11:26:38 AM - Error: Code=; Message=A task was canceled.
, 11:26:38 AM - Error: Code=; Message=A task was canceled.
It will be helpful to add retry policies such as exponential back off, linear retries, etc. to handle transient failures. At the moment, any timeout is an out right failure even when ARM is continuing to deploy the resources in the background.
Would like this as well please. Just hit a timeout in Set-AzSqlElasticPool when setting a maintenance window. The Azure Portal states this could take several minutes. A timeout of 100 seconds is not going to be enough. So I'd like to be able to configure it.
Also having this issue with get-azsqldatabase and get-azsqlserver and other azure cmdlets including new-azsqldatabasecopy used in our DevOps Pipeline. What is worse it's an intermittent issue, causing builds to randomly fail. Quite Frustrating. ##[error]The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
We have the same problem with intermittent failures in automation. It's not practical to add manual retry loops on every single call, but without better timeout control it makes any kind of infrastructure maintenance written in powershell unreliable. This really seems like an oversight. We're close to writing our own bindings for powershell.
Same issue - not being able to configure timeouts like this makes PS automation basically useless (i.e. unreliable) for any Enterprise situation.
Need this too! Some Az Modules need more time as 100 secs. For example mass deployment parts. Have parameters already been built for it? @dingmeng-xue
Need this too! Some Az Modules need more time as 100 secs. For example mass deployment parts. Have parameters already been built for it? @dingmeng-xue
We recently re-evaluated this requirement and will continue to update this issue.
Got long running script parsing my Azure with many resources... got transient timeout issues sometimes followed by SSL connections errors.
Retries and Timeout adjustment would be really welcome to let those long running scripts go to their end without discrepancies.
I'd also like to see this implemented. I'm hitting 100s HttpClient timeouts within long running scripts occasionally, in the most recent case using Get-AzDnsRecordSet.
Same problem here:
PS ERROR: (TaskCanceledException): The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing. StackTrace: at New-AzConfigurationAssignment
As of now, I don't know how to bypass this error.
