Graph API throws "$count is not currently supported." when you KNOW it's supported?

This post was most recently updated on September 25th, 2021.

2 min read.

Hey, another funny case. “Funny” as in “the error message is misleading and googling didn’t really help”, but also as in “a colleague knew the answer right off the bat because he already fixed it in another project”.

This time the documentation was in fact there, it just wasn’t there to be found.

Anyway – what have I broken this time?

Problem

Table of Contents

When you’re calling Graph API with both $filter and $count, for example:

https://graph.microsoft.com/v1.0/users/$count?$filter=assignedLicenses/any(x:x/skuId eq 189a915c-fe4f-4ffa-bde4-85b9628d07a0)

Instead of the expected number of found items, you get results like this even though you’re pretty sure your syntax is just peachy:

{
    "error": {
        "code": "Request_BadRequest",
        "message": "$count is not currently supported.",
        "innerError": {
            "date": "2020-12-01T19:10:25",
            "request-id": "645f1148-040e-4cf9-8aed-7e8acc88f4bc",
            "client-request-id": "c35759ce-2d8a-56f8-032c-1bc65e612b5d"
        }
    }
}

“$count is not currently supported.” – really? I happen to KNOW it is supported for filtered user collections on Graph API.

.. so what gives?

Solution

Well, once again, the solution turned out to be simple.

Some calls to Graph API with $count (and $search) require the consistency level to be set to “eventual”. In Graph Explorer, that’s done like shown below:

How to add a request header in Graph Explorer?

Key: “consistencylevel”
Value: “eventual”

Or in C#, it’s done like this:

using (var request = new HttpRequestMessage(HttpMethod.Get, url))
{
	request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", yourAccessToken);
	request.Headers.Add("consistencylevel", "eventual");

	var result = httpClient.SendAsync(request).GetAwaiter().GetResult();

	// your code here
}

And with that, you should be good!

But what is “eventual consistency”? Microsoft defined it like this a while back:

What is eventual consistency?

Azure Active Directory stores multiple copies of data to handle large read volume and provide high availability. When data is updated, the change will eventually be applied to all the copies.

$search and $count queries require the client to opt-in for eventual consistency by setting the header ConsistencyLevel = eventual.

For example, this means that when you add a user, you need to wait for all the copies to be updated to search or count them.
https://developer.microsoft.com/en-us/graph/blogs/build-advanced-queries-with-count-filter-search-and-orderby/

References

The credit for this one actually goes to my coworker Marcin Wojciechowski, who figured out the issue but doesn’t want to blog about small topics like this :)

He shares his more thorough articles about Microsoft 365 / Azure-related topics at his blog – check it out!

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)