Deployment to Windows app service has stopped working in 1.9.4

[TWolversonReply]

• [ ] Make sure you've installed the latest version using instructions in the wiki

Output from azd version 1.9.4

Describe the bug Between 1.9.3 and 1.9.4, deployment of a .NET web app to a Windows app service has started failing with the error message

ERROR: failed deploying service 'web': deploying service web: empty deployment status id

The code being deployed is from a universal package on the same version as before, so I'm certain it isn't our code change reponsible, since there hasn't been any.

Expected behavior Deployment works

Environment Information on your environment:

• Language name and version
• IDE and version : [e.g. Visual Studio 16.3]

Additional context

I would imagine this has been introduced by https://github.com/Azure/azure-dev/pull/3965 Add deployment status tracking for linux web apps.

Fixing the installed azd version in the ADO install-azd pipeline component to 1.9.3 fixes the problem.

[TWolversonReply]

I would add that this breaks Logic Apps Standard in totality since they are obligatory to Windows app service

[rajeshkamal5050]

@hemarina can you look into this? cc @weikanglim @vhvb1989

[hemarina]

@TWolversonReply Could you share which azd template/bicep file you are using?

[jongio]

I switched todo-csharp-sql to windows and I couldn't repro this - it deployed. @TWolversonReply it would be helpful to get more context on how you've structured your app so we can try to get a repro.

[TWolversonReply]

@hemarina @jongio I'm under NDA for this work so probably can't share the actual code, and will need to find some time to provide a repro.

The PR linked above seems feasible - it's entirely possible that it's some permutation of app service properties we're setting that triggers the issue. We have retrofitted an old solution to support azd, so whatever it always used to do for IaC is what it does now and it won't be following any unspoken norms applied by the sample templates. We don't set anything for the linuxFxVersion property as mentioned in the linked PR - why would we, our solution is nothing to do with Linux. I'm well aware of the extremely leaky abstractions of many of the ARM provider APIs though and the many poorly documented permutations of properties expected that will break resources in unpredictable ways if not set the way the provider wants.

Pruning what I don't think is meaningful this is the essence of our site resource template:

    {
      "apiVersion": "2021-03-01",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('ASPName'))]"
      ],
      "location": "[resourceGroup().location]",
      "name": "[variables('AdminSiteName')]",
      "properties": {
        "siteConfig": {
          "metadata": [
            {
              "name": "CURRENT_STACK",
              "value": "dotnet"
            }
          ],
          "netFrameworkVersion": "v6.0"
        },
        "httpsOnly": true
      },      
      "type": "Microsoft.Web/sites"
    }

[WorkJelle]

I had this problem aswell with Logic app Standard. My serverplan is on a different resourcegroup than where my logic app standards are hosted. So during my provisioning state everything seems to be going well. In the json view you can see that the serverfarmId is correctly configured.

"/subscriptions/<subId>/resourceGroups/shared-dev/providers/Microsoft.Web/serverfarms/plan-logic-shared-dev"

However during the deploy state, where the files get packaged and sent it will give out the error:

{
  "error": {
    "code": "ResourceNotFound",
    "message": "The Resource 'Microsoft.Web/serverFarms/plan-logic-shared-dev' under resource group 'd365fscm-dev' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix"
  }
}

d365fscm-dev resourcegroup = the place where my logic app standard will reside Shared-dev resourcegroup = the place where the app service resides

During the deploy step in the deployment you can see that it tries to do a GET request towards, where the serverfarm isn't even located.:

"https://management.azure.com/subscriptions/<subId>/resourceGroups/d365fscm-dev/providers/Microsoft.Web/serverfarms/plan-logic-shared-dev"

My temporary fix now is just to use version 1.9.3 to atleast make my deployments work

[TWolversonReply]

@WorkJelle I encountered this problem as well, which I think is actually a different issue. I mentioned this in #4072 which has now been closed.

[hemarina]

@TWolversonReply The deployment status api only works for linux web app. Expected behavior is that serverfarms or logic app should not trigger this api. We have the fixes for IsLinuxWebApp to make sure the api is triggered only for linux web app in https://github.com/Azure/azure-dev/pull/4073. 1.9.5 is out. Could you try use and see if it works?