Transitive Dependencies and namedValues issues

Start by reproducing apiops extract with a named value whose displayName differs from its name, then inspect the Transitive Dependency Resolver's lookup and Management API request. Compare the behavior with --no-transitive and manual dependencies. Done means extraction resolves the displayName to the Management API name and succeeds for the described named-value case.

Command that triggered the bug

apiops extract

Expected behavior

Hello,

The ApiOps-CLI Transitive Dependencies resolver seems to have issues with extracting namedValues when the "name" property of the namedValue is different than the "displayName" property of the namedValue.

According to Microsoft's documentation, referencing a namedValue in a policyFragment is done using it's displayName property the following way {{display_name}} (ref: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-properties?tabs=azure-portal#use-a-named-value). This is how we have also configured the policyFragments on our APIM Instance.

However, the APIM Management API will fetch details about a named value using the name property instead of displayName (ref: https://learn.microsoft.com/en-us/rest/api/apimanagement/named-value/get?view=rest-apimanagement-2024-05-01&tabs=HTTP):

GET https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg1/providers/Microsoft.ApiManagement/service/apimService1/namedValues/testarmTemplateproperties2?api-version=2024-05-01

{
"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg1/providers/Microsoft.ApiManagement/service/apimService1/namedValues/testarmTemplateproperties2",
"type": "Microsoft.ApiManagement/service/namedValues",
"name": "testarmTemplateproperties2",
"properties": {
"displayName": "propName",
"value": "propValue",
"tags": [
"foo",
"bar"
],
"secret": false
}
}

What happens when we use the Transitive Dependency Resolver seems to be that when the API definition is parsed, the Resolver notices the "displayName" property of the namedValue inside one of the API's policyFragments. It then calls the Managemend API using the "displayName" property of the namedValue which obviously fails the API Call, as the Management API Call is not correct, therefore the extraction fails.

While I can understand that maybe having different values for the "displayName" and "name" properties of a namedValue is atypical, as far as I understand both properties are unique on APIM level (otherwise, you wouldn't be able to fetch a single value using "name" with the ManagementAPI, and the policyFragment would be confused by duplicated "displayName" properties) and it's also not a scenario that Microsoft prevents in any way or even recommends against.

My curiosity is if this bug is known to happen when "displayName" and "name" properties of a namedValue are different and if a mechanism that would pre-validate namedValues with the Transitive Dependency Resolver could be implemented. If it could build an map of key : value pairs formed from the "displayName" : "name" properties of namedValues in memory, then a check could be done for the "displayName" of a namedValue of an API's policyFragment in order to find it's "name" and then do the correct Management API call to fetch this namedValue.

For reference the namedValue we had issues with is KV referenced, not sure if there is any difference in processing ApiOps does for KV references compared to plain text or secrets namedValues.

Running ApiOps with the --no-transitive flag and manually specifying dependencies works fine.

Actual behavior

ApiOps extraction fails due to broken API Call.

apiops CLI version

1.0.2

Environment details

Private APIM instance, extraction and publish running from CI/CD.

CI/CD environment

Yes, GitLab CI/CD

Is this bug blocking you?

Not necessary, but makes maintaining the extraction parameters file more difficult when such a cool feature like the Transitive Dependency Resolver exists.