Express Route Circuit (2020-05-01): creation eventual consistent

[magodo]

Reproduce

1. Create an Express Route Circuit and wait till finish (via polling the operation url)
2. Delete it and wait till finish (via polling the operation url)
3. Create another Express Route Circuit with the same name and wait till finish (via polling the operation url)
4. Invoke a GET right after step 3, it returns 404.

Hence, clients can not rely on the polling result of the operation URL, but have to poll via GET until GET returns 200.

The Sequence

Create a express route circuit:

PUT https://management.azure.com/subscriptions/0-0-0-0/resourceGroups/acctestRG-200715135929363936/providers/Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936?api-version=2020-05-01

REQUEST

{
    "location": "eastus2",
    "properties": {
        "allowClassicOperations": false,
        "serviceProviderProperties": {
            "bandwidthInMbps": 50,
            "peeringLocation": "Silicon Valley",
            "serviceProviderName": "Equinix"
        }
    },
    "sku": {
        "family": "MeteredData",
        "name": "Standard_MeteredData",
        "tier": "Standard"
    },
    "tags": {
        "Environment": "production",
        "Purpose": "AcceptanceTests"
    }
}

RESPONSE

{
    "etag": "W/\"f1fe06f4-8be0-40f1-9538-87802fada321\"",
    "id": "/subscriptions/0-0-0-0/resourceGroups/acctestRG-200715135929363936/providers/Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936",
    "location": "eastus2",
    "name": "acctest-erc-200715135929363936",
    "properties": {
        "allowClassicOperations": false,
        "allowGlobalReach": false,
        "authorizations": [],
        "circuitProvisioningState": "Disabled",
        "globalReachEnabled": false,
        "peerings": [],
        "provisioningState": "Updating",
        "resourceGuid": "fd7cd84f-d786-4358-a869-626458bd3dde",
        "serviceKey": "00000000-0000-0000-0000-000000000000",
        "serviceProviderProperties": {
            "bandwidthInMbps": 50,
            "peeringLocation": "Silicon Valley",
            "serviceProviderName": "Equinix"
        },
        "serviceProviderProvisioningState": "NotProvisioned"
    },
    "sku": {
        "family": "MeteredData",
        "name": "Standard_MeteredData",
        "tier": "Standard"
    },
    "tags": {
        "Environment": "production",
        "Purpose": "AcceptanceTests"
    },
    "type": "Microsoft.Network/expressRouteCircuits"
}

Repeatedly poll the async operation URL, until:

GET https://management.azure.com/subscriptions/0-0-0-0/providers/Microsoft.Network/locations/eastus2/operations/5bc6316f-611f-4b8f-aec0-b15298534811?api-version=2020-05-01

{
    "status": "Succeeded"
}

Invoke a GET right after:

GET https://management.azure.com/subscriptions/0-0-0-0/resourceGroups/acctestRG-200715135929363936/providers/Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936?api-version=2020-05-01

{
    "error": {
        "code": "ResourceNotFound",
        "message": "The Resource 'Microsoft.Network/expressRouteCircuits/acctest-erc-200715135929363936' under resource group 'acctestRG-200715135929363936' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix"
    }
}

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @mialdrid, @aznetsuppgithub.

[xseeseesee]

@magodo Could you please share which SDK you are using? I just added label of Service Attention so that service team could also pay attention on this issue.

[magodo]

Hey @xccc-msft Essentially it doesn't matter which SDK underused, the issue exists even when using cURL to send API requests.

[xseeseesee]

@magodo Got it. I thought it might be caused by the polling scenario on SDK side. Then let's get help from service team.

[magodo]

@xccc-msft Unfortunately, the polling logic is correct. It returns when the async operation finishes with "Succeeded" provision state. While a GET right after returns 404, which means there is a synchronization issue on service side.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @exrsuppgithub.