Problems updating `AppService.appSettings`

1. It seems updating/adding a value on an AppService’s appSettings does not work. I get the following error:

PS D:\Code\pulumi-test> pulumi update
Previewing update of stack 'pulumi-test'
Previewing changes:

     Type                         Name     Plan       Info
 ~   azure:appservice:AppService  testApp  update     changes: ~ appSettings

info: 1 change previewed:
    ~ 1 resource to update
      7 resources unchanged

Do you want to perform this update? yes
Updating stack 'pulumi-test'
Performing changes:

     Type                         Name     Status                  Info
 ~   azure:appservice:AppService  testApp  **updating failed**     changes: ~ appSettings, 2 errors

Diagnostics:
  azure:appservice:AppService: testApp
    error: Plan apply failed: updating urn:pulumi:pulumi-test::pulumi-test::azure:appservice/appService:AppService::testApp: web.AppsClient#CreateOrUpdate: Failure sending request: StatusCode=409 -- Original Error: failed request: autorest/azure: Service returned an error. Status=<nil> <nil>

    error: update failed

info: no changes required:
      7 resources unchanged

Permalink: https://app.pulumi.com/loic-sharma/pulumi-test/updates/11
error: update failed

I can get around this by doing pulumi destroy followed by a pulumi update.

1. It seems that changing an AppService’s appSettings’s value from a string to an Output<string> doesn’t get detected. Example from:

appSettings: {
  "Hello": "World"
}

Example to:

appSettings: {
  "Hello": all([output1, output2]).apply(([a, b]) => `${a} ${b}`)
}

Running pulumi update will result in a preview of no changes.

[lukehoban]

Given how pervasive use of AppService is, this feels important to root cause.

[jen20]

Hi @juchom! Sorry for the delay in responding here. I just tried reproducing this with the latest versions of the Pulumi CLI (v0.17.1) and pulumi-azure (v0.17.2), using your detailed (thank you!) AppService example of adding Application Insights. I believe this was one of a class of bugs fixed by @pgavlin’s recent work to improve handling of default values.

After running the second part of the example, I see the following in the Azure Portal:

I’ll mark this issue as closed since it no longer reproduces - if you spot conditions where it is still an issue, please feel free to re-open!