Optimizing subscription query using filter for GET /subscriptions

Question

Optimizing subscription query using filter for GET /subscriptions

Anonymous

Our application needs to manage tens of thousands of subscriptions. GET /subscriptions doesn't support $select or $filter, so when the app checks if a subscription exists, it has to compare it to every subscription, leading to O(N^2) complexity. Is there a way to filter better?

Steve Norwood 55 Reputation points

2024-06-18T15:51:16.83+00:00
Is there any feedback on this?

If you go to the graph explorer, and put the default request for listing all subscriptions (https://graph.microsoft.com/v1.0/subscriptions), you get the following response:

{ "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#subscriptions", "@microsoft.graph.tips": "Use $select to choose only the properties your app needs, as this can lead to performance improvements. For example: GET subscriptions?$select=applicationId,changeType", "value": [] }

Note: for some reason I only get this message if I'm signed in, and not on the sample account that the graph explorer provides.

However, if you try to use the $select option like the tip suggests (https://graph.microsoft.com/v1.0/subscriptions?$select=applicationId,changeType), you get an error:

{ "error": { "code": "", "message": "The query specified in the URI is not valid. Query option 'Select' is not allowed. To allow it, set the 'AllowedQueryOptions' property on EnableQueryAttribute or QueryValidationSettings.", "innerError": { "date": "2024-06-18T15:42:12", "request-id": "091e5b9b-c84a-47b8-b030-24c55c751eae", "client-request-id": "2b1d41f1-5d4a-c311-9fa6-3a7e55f0d75d" } } }

This seems extremely odd, as the tip is quite clearly suggesting to do something that simply doesn't work. Furthermore, the reason I came across this is because I wanted to use the $filter to search for specific subscriptions, but this is not supported either. For example if I wanted to do ?$filter=startswith(resource, 'test') then you get a very generic error:

{ "error": { "code": "QueryNotSupported", "message": "The query is not supported.", "innerError": { "date": "2024-06-18T15:45:16", "request-id": "e1d7b50b-c161-4b88-bc05-3853eb6b5b7b", "client-request-id": "f82b8c6a-f477-c056-449d-05066b4b1e99" } } }

I have tried this with ConsistencyLevel eventual and $count=true and this does not make a difference either.

This seems very inconsistent with other areas of the Graph API I have used, so I feel like this is a bug, especially how filtering on this particular endpoint is especially critical as the original post has mentioned

Share via

Optimizing subscription query using filter for GET /subscriptions

Your answer