[BUG] Multiple APIs of "Azure.ResourceManager.CostManagement.CostManagementViewsCollection" have parameter mismatches.

[lsl-2020]

Library name and version

Azure.ResourceManager.CostManagement Version 1.0.1

Describe the bug

Multiple APIs of Azure.ResourceManager.CostManagement.CostManagementViewsCollection calls Azure.ResourceManager.CostManagement.ViewsRestOperations methods. However there are mismatch between caller and callee parameter types.

For example, Azure.ResourceManager.CostManagement.CostManagementViewsCollection.GetIfExistsAsync(String viewName, CancellationToken cancellationToken) calls Azure.ResourceManager.CostManagement.ViewsRestOperations.GetByScopeAsync(Id, viewName, cancellationToken: cancellationToken).ConfigureAwait(false); However, the first parameter Id in this caller is Azure.Core.ResourceIdentifier type, while the callee method is public async Task<Response<CostManagementViewData>> GetByScopeAsync(string scope, string viewName, CancellationToken cancellationToken = default) with first parameter as string type. Details can be seen in error screenshot below.

Expected behavior

Get 200 as status code, whether certain resource group view exists or not.

Actual behavior

Reproduction Steps

1. Checkout tag Azure.ResourceManager.CostManagement_1.0.1
2. Go to "Azure.ResourceManagement.CostManagement/Generated/CostManagementViewsCollection.cs", line 153.
3. See the mismatch of first parameters as below:

If you need my initial codes to discover the mismatch, here it is:

[HttpGet(Name = "GetIfExists_ResourceGroupView")]
public async Task<CostManagementViewData?> GetIfExists_ResourceGroupView([FromQuery] string viewName)
{
    TokenCredential cred = new DefaultAzureCredential();
    ArmClient client = new ArmClient(cred);

    string scope = $"subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}";
    ResourceIdentifier scopeId = new ResourceIdentifier(string.Format("/{0}", scope));
    CostManagementViewsCollection collection = client.GetAllCostManagementViews(scopeId);

    ////string viewName = "swaggerExample0";
    ////string viewName = "DailyCosts";
    NullableResponse<CostManagementViewsResource> response = await collection.GetIfExistsAsync(viewName);
    CostManagementViewsResource? result = response.HasValue ? response.Value : null;

    if (result == null)
    {
        Console.WriteLine($"Succeeded with null as result");
        return null;
    }
    else
    {
        CostManagementViewData resourceData = result.Data;
        Console.WriteLine($"Succeeded on id: {resourceData.Id}");
        return resourceData;
    }
}

Environment

Microsoft Visual Studio Enterprise 2022 (64-bit) - Preview Version 17.10.0 Preview 4.0

[github-actions[bot]]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[lsl-2020]

What confuses me is that sometimes they throw exception of parameter mismatch but sometimes everything seems to be absolutely normal and the job gets done smoothly (very rare situation though). For example I've seen Azure.ResourceManager.CostManagement.CostManagementViewsCollection.CreateOrUpdateAsync(WaitUntil waitUntil, string viewName, CostManagementViewData data, CancellationToken cancellationToken = default) get executed okay for twice (despite the Etag issue).

[lsl-2020]

Found the code in tenant part seems okay (var response = await _tenantsCostManagementViewsViewsRestClient.CreateOrUpdateAsync(Id.Name, data, cancellationToken).ConfigureAwait(false); , so maybe a simple fix PR to replace Id to Id.Name will work.

[HarveyLink]

Hi @lsl-2020 , could you provide the error scope values you have for us so that we could test on those.

[github-actions[bot]]

Hi @lsl-2020. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[github-actions[bot]]

Hi @lsl-2020, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!