Unexpected error when using the wrong ADO build agent

I am currently doing some Azure deployment work using Azure DevOps. The target Azure configuration has a mixture of publicly accessible resources and private ones only available via a vNet and private endpoints.

Whilst getting this deployment setup I made a mistake and configured an ADO pipeline job to use an ADO self hosted agent, as opposed to a Microsoft hosted agent. The self hosted agent was on the private vNet and was intended to only deploy to the private resources on that vNet and hence had limited access to the wider set of Azure resources.

I had expected this mistake would not be a major issue, assuming that the pipeline run should fail fast with a 404 or 403 error due to the lack of access to the target Azure resource.

However this was not the case, the task AzureRmWebAppDeployment@5 took 17 minutes to fail with the error Client network socket disconnected before secure TLS connection was established

Starting: Deploy Management API to Azure Web App
==============================================================================
Task         : Azure App Service deploy
Description  : Deploy to Azure App Service a web, mobile, or API app using Docker, Java, .NET, .NET Core, Node.js, PHP, Python, or Ruby
Version      : 5.279.2
Author       : Microsoft Corporation
Help         : https://aka.ms/azureappservicetroubleshooting
==============================================================================
Got service connection details for Azure App Service:'app-mgmtapi-dev-westeurope'
Package deployment using One Deploy initiated.
##[error]Failed to deploy web package to App Service.
##[error]Error: Error: Failed to deploy web package to App Service. Error: Client network socket disconnected before secure TLS connection was established
##[warning]Error: Failed to update deployment history. Error: Error: Client network socket disconnected before secure TLS connection was established
App Service Application URL: https://app-mgmtapi-dev-westeurope.azurewebsites.net
Finishing: Deploy Management API to Azure Web App

If you enable the debug log, you can see the task repeatedly retrying the connection.

There is no fix here to document, other than to use the correct agent for your configuration.

However, I thought it worth writing this post as a note to my future self, and others, as a reminder as to how much this task can retry before finally failing, and how the error message can be confusing. Suggesting a certificate issue or similar when it is just an access issue.

For the original version of this post see Richard Fennell's personal blog at Unexpected error when using the wrong ADO build agent