-1

we have an application that is processing incoming emails. Every now and then we are getting timeouts from Graph. However we are not retrieving lots of data.

An example of one call where we get a timeout is:

var folder = await client.Users[targetMailbox].MailFolders[targetFolder].GetAsync(options =>
{
    options.QueryParameters.Select = new[] { "id" };
});

Where the targetFolder is the wellknown name "inbox".

Another is where we are searching for an email which matches an internetMessageId:

var messages = await client.Users[mailbox].Messages.GetAsync(options =>
{
    options.QueryParameters.Select = new[] { "id" };
    options.QueryParameters.Filter = $"internetMessageId eq '{internetMessageId}'";
});

We aren't setting any limit, so should be using the limit of 100, but we would expect in the general case it would only be 1 result (but could be more).

We can see that the GatewayTimeout happens after 30 seconds. I've read other users reporting this issue, but usually it is where they are getting large pages of results, we are simply attempting to get the id of a wellknown folder.

On top of this, the Kiota RetryHandler is kicking in, and so does further attempts but then errors. We see multiple attempts that error with the GatewayTimeout exception, and finally we see the ServiceUnavailable error, with the details stating "Command Concurrency Limit Reached".

So it appears that not only is Graph taking a ridiculous amount of time to return a single folder id, but when it does return the GatewayTimeout, it still thinks that the command is running, so when the retryhandler tries a couple more times, we start seeing concurrency limit errors.

Has anyone got a clue to what we could do to resolve this? If we try again a number of minutes later, it all seems to work fine.

I've seen on other posts MSFT users asking for request id details, spo include them here in case anyone can assist:

{"error":{"code":"UnknownError","message":"","innerError":{"date":"2025-12-10T15:02:44","request-id":"40d6ec71-fcd3-4c5a-828a-bad2460cf485","client-request-id":"ac6171dc-6d28-4107-b463-5295ccd05329"}}}

Thanks,

Chris

4
  • Cf. https://learn.microsoft.com/en-us/graph/throttling Commented Dec 12, 2025 at 15:21
  • Hi, this is not happening when our code is calling concurrently, this is happening when graph reports a GatewayTimeout, which appears to happen when the upstream query (which is basic) is for some reason taking longer than 30 seconds. This then seems to leave the connection recorded against the mailbox and app as still running, and counting towards the concurrency limits. Kiota is then doing multiple retries, having the same issue, resulting in a concurrency limit being hit. Therefore: 1) Why is graph timing out upstream. 2)Why is GatewayTimeout error not releasing the connection count. Commented Dec 16, 2025 at 16:28
  • Could you provide more details or share your code to help us understand better? One of these links might help you: https://stackoverflow.com/questions/57892255/getting-error-504-gateway-timeout-while-fetching-messages-from-the-ms-graph-ap and https://learn.microsoft.com/en-us/answers/questions/1359336/graph-api-returns-504-error-even-for-single-cell-v Commented Dec 17, 2025 at 14:42
  • I've already included the lines of code in my original post, really nothing too taxing I wouldn't have thought, and certainly they normally return very quickly, ie <1 second, but we are getting a few a day where they timeout after 30 seconds with the GatewayTimeout with the exact same calls. When this happens, we are not calling concurrently or doing retries ourselves, the only retries that are happening are from kiota (we are using >1.17). And after it has retried a couple of times it gets the concurrent error, it seems the connections aren't being discounted with a GatewayTimeout Error. Commented Dec 18, 2025 at 15:16

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.