armlocks api-version issue

[simongottschlag]

Bug Report

Hi!

I'm using armlocks (github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resources/armlocks) version v1.0.0 in the following way:

    client, err := armlocks.NewManagementLocksClient(subscriptionID, cred, &arm.ClientOptions{})
    if err != nil {
        return err
    }

    _, err = client.GetAtResourceLevel(ctx, resourceGroupName, resourceProviderNamespace, parentResourcePath, resourceType, resourceName, lockName, &armlocks.ManagementLocksClientGetAtResourceLevelOptions{})
    if err == nil {
        return nil
    }

I get the following error:

GET https://management.azure.com/subscriptions/subid/resourcegroups/rgname/providers/Microsoft.Storage//storageAccounts/saname/providers/Microsoft.Authorization/locks/DoNotDelete
--------------------------------------------------------------------------------
RESPONSE 400: 400 Bad Request
ERROR CODE: NoRegisteredProviderFound
--------------------------------------------------------------------------------
{
  \"error\": {
    \"code\": \"NoRegisteredProviderFound\",
    \"message\": \"No registered resource provider found for location 'westeurope' and API version '2020-05-01' for type 'locks'. The supported api-versions are '2015-01-01, 2015-05-01-preview, 2015-06-01, 2016-09-01, 2017-04-01'. The supported locations are ''.\"
  }
}
--------------------------------------------------------------------------------

I am able to work around the issue by doing the following:

type fixApiVersionTransporter struct {
    apiVersion string
    httpClient *http.Client
}

func (t *fixApiVersionTransporter) Do(req *http.Request) (*http.Response, error) {
    reqQP := req.URL.Query()
    reqQP.Set("api-version", t.apiVersion)
    req.URL.RawQuery = reqQP.Encode()

    return t.httpClient.Do(req)
}

func foo(...) error {
    client, err := armlocks.NewManagementLocksClient(subscriptionID, cred, &arm.ClientOptions{
        ClientOptions: policy.ClientOptions{
            Transport: &fixApiVersionTransporter{
                apiVersion: "2016-09-01",
                httpClient: http.DefaultClient,
            },
        },
    })
    if err != nil {
        return err
    }

    _, err = client.GetAtResourceLevel(ctx, resourceGroupName, resourceProviderNamespace, parentResourcePath, resourceType, resourceName, lockName, &armlocks.ManagementLocksClientGetAtResourceLevelOptions{})
    if err == nil {
        return nil
    }
}

There seems to be some kind of issue with the default version being used. I've specifically seen the issue with locks on storageAccounts.

[ghost]

Thank you for your feedback. This has been routed to the support team for assistance.

[tadelesh]

Need service team to check why 2020-05-01 not work for locks API (defined in: https://github.com/Azure/azure-rest-api-specs/blob/80065490402157d0df0dd37ab347c651b22eb576/specification/resources/resource-manager/Microsoft.Authorization/stable/2020-05-01/locks.json#L5).

[navba-MSFT]

@simongottschlag Thanks for reaching out to us and reporting this issue. We are looking into this issue and we will provide an update.

[navba-MSFT]

@simongottschlag I am able to reproduce the issue at my end. I tried to invoke this REST API using api-versions 2016-09-01 and 2017-04-01 and it worked. However, the api-version='2020-05-01' is failing while we invoke the Get the management lock of a resource rest api. I am doing some more research on this and I will update this GitHub thread once I have more details.

[navba-MSFT]

@simongottschlag I had reached out to the Product owners in the background and we’ve run into similar issues in the past where the API version listed as being supported in the resource provider’s manifest doesn’t align to what’s in swagger (or vice versa). We are now tracking this issue in our backlog, but we can’t yet commit to when it will be fixed. In the meantime if you have any follow-up questions, feel free to ask.

[simongottschlag]

Thanks @navba-MSFT!

I have a workaround and mostly created the issue to make sure others who hit the same issue doesn't have to figure it out themselves as well as making sure it's resolved in the end. 😊👍

[navba-MSFT]

@simongottschlag I am glad that you are unblocked for now. Thanks for reporting this issue and providing the feedback. Please let us know have any follow-up questions, feel free to ask.

[navba-MSFT]

@simongottschlag No ETA for the fix release just yet. We have got the workitem details too internally to keep a track on this Bug. So proceeding with archival of this thread.

[navba-MSFT]

@simongottschlag As an update, we’ve determined that the api-version ‘2020-05-01’ isn’t valid and was wrongly incremented. We are updating the related documentation and Swagger so that the lock docs reflect the appropriate version.