2 strange adventures with IpSecurityRestrictions in SiteConfig of WebApp

[PawelStadnicki]

Adventure 1:

following code will make the program to hang out for several minutes with not descriptive error of Code="Failed" Message="The async operation failed." AdditionalInfo=[{"Message":"An error has occurred."}]:, with debug or verbose modes not helping too much or even worsening the situation pointing on random earlier invocations:

Notice that this code, strict null in specific, I simplified it to the root cause , my code has some abstractions (Template Method) that due to unfinished implementation ,resulted in this null. So despite I had the problem with my code I think the error result should be better described somehow (if this is possible) and the program should fail fast, not hang out.

So it doesn't have a significant impact but it may be related to my second adventure:

Adventure 2: if I put the following code for IP restrictions:

new IpSecurityRestrictionArgs
            {
                Action = "Allow",
                Priority = 1,
                Name = "Allow xxx",
                IpAddress = "xxx"
            };

it provisions restriction nicely. However, when I'm importing WebApp with such SiteConfig, Pulumi doesn't see it (ipsecurityrestriction) exists and wants to add it again. I know there was/is a lot of issues with SiteConfig, hope this one is not a one of them and can be solved.

[danielrbradley]

Hi, to clarify - is the first issue that it fails if you provide a list which contains a null entry - or only a null entry?

Also, would you be able to provide a more complete Pulumi program which produced the second issue?

[mikhailshilkov]

I believe (2) is caused by https://github.com/Azure/azure-rest-api-specs/issues/12104 and (1) is caused by App Service swallowing all useful error messages and returning "The async operation failed." all the time.

Since we don't have a clean repro, I'll close this issue for now - anyone reading this feel free to report a fuller repro as a new issue.

[aureq]

@mikhailshilkov I'm reopening this issue for tracking purpose of affected customers, despite the issue being with the Azure API.

As a repro, the code is provided below. Here are the steps:

1. Deploy the code below ✅
2. Go to the Azure portal and locate the webapp
3. Under networking, go to the IP Security Restrictions
4. Add a new restriction and save the changes
5. Run pulumu up --refresh. No changes is detected ❌
6. Remove a restriction and save the changes
7. Run pulumu up --refresh. No changes is detected ❌

import * as pulumi from "@pulumi/pulumi";
import * as azure_native from '@pulumi/azure-native';

const rg = new azure_native.resources.ResourceGroup('resourceGroup', {
    location: 'westeurope',
    resourceGroupName: 'my-resource-group',
});

const appServicePlan = new azure_native.web.AppServicePlan('appServicePlan', {
    kind: 'linux',
    location: rg.location,
    name: 'sp-7d8e82f8-6758',
    resourceGroupName: rg.name,
    sku: {
        name: 'b1',
    },
});

const webApp = new azure_native.web.v20230101.WebApp('webApp', {
    kind: 'app,linux,container',
    location: rg.location,
    name: 'webapp-7d8e82f8-6758',  // this name needs to be unique across Azure
    resourceGroupName: rg.name,
    publicNetworkAccess: 'Enabled',
    serverFarmId: appServicePlan.name,
    siteConfig: {
        ipSecurityRestrictions: [
            // Initial creation
            {
                ipAddress: '8.8.8.8/32',
                action: 'Allow',
                tag: 'Default',
                priority: 1000,
                name: 'googledns',
            },
            {
                ipAddress: 'Any',
                action: 'Deny',
                priority: 2147483647,
                name: 'Deny all',
                description: 'Deny all access',
            },
        ],
        ipSecurityRestrictionsDefaultAction: 'Deny',
    },
}, {
    deleteBeforeReplace: true,
});

[mikhailshilkov]

As a reference point, the classic provider makes a separate call to read WebApp configuration while reading the resource state here. We'll probably have to do the same to fix this issue in the native provider.

[pulumi-bot]

This issue has been addressed in PR #3464 and shipped in release v2.52.0.