Race condition in ARM template

[glahaye]

Describe the bug
When deploying the Azure resources from main.bicep / main.json, we hit errors like the following:

ERROR TYPE
Deployment was interrupted and the process running it was terminated unexpectedly, if an ARM template is used, the likely cause is a race condition. To solve the race condition, make all resources that could potentially restart the site (app settings or site config changes for example) have a dependency on MSDeploy resource. For more info please read the information here: http://go.microsoft.com/fwlink/?LinkId=808141 (Code: Failed)

To Reproduce
Deploy CC resources from scratch to Azure using either deploy-azure script or Deploy to Azure button.

Expected behavior
Error-free deployment of resources to Azure

Related: #488 #498

[glahaye]

Usually, this type of error is due to more than one resource being deployed on top of a "Microsoft.Web/sites" server.

Each resource deployed to the server (MSDeploy extension, Application Insights extension, site configuration) causes it to restart. If the server restarts while another of these resources is being deployed, this latter deployment will fail because it will be interupted by the restart.

The usual solution to this problem is to chain the resource deployments to the server serially using "dependsOn" clauses instead of letting them happening in parallel,

Despite having chained all resource deployments to the server in the CC bicep / ARM template, we still get this error.

The problem seems particularly acute (or even exclusive?) to the appServiceMemoryPipeline server.

[crickman]

@alliscode - Can you review where this is at a determine next steps?

[crickman]

Apparently there is a response to Gil's stack-overflow query: https://stackoverflow.microsoft.com/questions/375089/375405

[jopapeador18]

I'm sorry, what would be the answer then ? Should we redeploy? I checked the template but it had the sentence dependon.

[glahaye]

@jopapeador18 You can always re-run a deployment right it fails (if it does).

At any rate, #564 we should be good and not encounter that problem anymore.