armresourcegraph: Inconsistent casing causes resources not to be found from graph API

[TBeijen]

Inconsistent casing, combined with ids being case-sensitive, causes resources not to be found from graph API.

Note: This seems to originate from the graph api itself, since https://portal.azure.com/#view/HubsExtension/ArgQueryBlade shows the same results.

I have a list of resource ids that originate from armauthorization.RoleAssignmentsClient, which I take from the responses Properties.Scope. I then use armresourcegraph to load the various types of resources to obtain tags.

This works in most cases, however, not for redis. The casing of the ID returned by armauthorization differs from what is expected by the graph API.

# ID as returned by armauthorization SDK.
# Does not return result in graph
Resources | where id == '/subscriptions/<my-sub>/resourceGroups/<my-rg>/providers/Microsoft.Cache/redis/<my-redis>' | project id, name, type, resourceGroup, tags

# Fixing casing to the exact type returned when fetching from cli (az resource show --ids "<the-id>")
* Note: redis -> Redis
Resources | where id == '/subscriptions/<my-sub>/resourceGroups/<my-rg>/providers/Microsoft.Cache/Redis/<my-redis>' | project id, name, type, resourceGroup, tags

I run use these queries via:

// *armresourcegraph.Client
ResourceGraphClient.Resources(context.Background(), armresourcegraph.QueryRequest{
            Query: to.Ptr(q),
        }, nil)

Some inconsistencies can be observed throughout the Azure landscape that make the graph API hard to navigate.

• Inconsistent strictness of id casing: When using cli az resource show --ids "<id-with-lowercase-redis"> this gives the result. The graph API does not. The az resource cli command uses dedicated per-resource APIs under the hood. Nevertheless confusing

• Inconsistent casing of types in ids: In id Microsoft.Cache/redis is incorrect, however Microsoft.KeyVault/vaults is correct

• Inconsistent response casing: The graph response type values are casted to lowercase, unlike the JSON response of az resource show. Querying the graph API by type requires this lower case. So querying by id and by type both use strict casing, but require a differently cased value.

I can imagine strict casing is important for all naming entered by users (rg names, resource names, tags, etc.). However the type attribute has a limited and well-defined set of values. Not checking for exact casing would make the armresources SDK and the graph API a lot easier to navigate.

To illustrate, I now have this code fragment to work around this issue:

fixedResourceID := strings.Replace(resourceID, "Microsoft.Cache/redis", "Microsoft.Cache/Redis", -1)

[lirenhe]

@tadelesh, could you provide some suggestion on this issue? thanks

[github-actions[bot]]

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

[tadelesh]

@chiragg4u is it by design that resource type is case sensitive? @JeffreyRichter could you also help to take a look? is their any standard for azure resource id/resource type of the casing?

[JeffreyRichter]

According to the industry standard RFC for URLs (https://datatracker.ietf.org/doc/html/rfc3986#section-6.2.2.1), URLs are supposed to be case-sensitive except for the scheme and host name).

Azure services should honor this, but (unfortunately) some do not, and this causes these kinds of problems. And because some engineers are not aware of the RFC, they think URLs are case-insensitive and so one engineer might return "redis" while another engineer writes code requiring "Redis".

So, case-sensitive comparisons are the correct thing. The team needs to agree on "redis" vs "Redis" and then stick to it consistently. This may require code changes. As a "quick-fix", a service could treat "redis" and "Redis" as the same (and maybe "REDIS" too) but this can lead to more problems in the future.