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.
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.