Microsoft Graph API 返回 503/504 错误 [英] Microsoft Graph API returning 503/504 errors

问题描述

我正在使用 Microsoft 的 Graph API Java 客户端从 Office365 获取消息.查询跨越一整年.它们每页限制为 50 个结果，并使用返回的下一页 URL 进行处理.每 5 分钟定期执行一次，但每个作业不超过 2 分钟(迭代下一个网址).

I'm fetching messages from Office365 using Microsoft's Graph API Java client. The queries span a whole year. They're limited to 50 results per page and progress using the returned next page URL. It's done periodically every 5 minutes, but no longer than 2 minutes per job (which iterates over the next url).

偶尔我会收到 503 Service Unavailable/504 Gateway Timeout.一旦发生这种情况，请求将无法继续进行，并且会继续遇到这些错误.

Once in a while I get 503 Service Unavailable / 504 Gateway Timeout. Once this happens, the request can't progress and will keep hitting those errors.

根据 Microsoft 的文档，这应该被视为请求过多，并延迟退出.发生这种情况时没有 Retry-After 标头.我注意到缩小时间范围并重新启动查询有时会有所帮助.我也在 Stackoverflow 上看到了这个问题，但没有解决方案.

According to Microsoft's documentation this should be treated as too many requests, and back off with a delay. There's no Retry-After header when this happens. I've noticed that making the time frame smaller and restarting the query can help sometimes. Also I've seen this raised on Stackoverflow but with no solutions.

我想知道是不是查询了一年太多了，即使有分页?除了退出之外，还有其他解决方案的想法吗?

I'm wondering is querying for a year too much, even though there's paging? Any ideas for solutions other than backing off, and for how long?

谢谢

失败的示例查询:

https://graph.microsoft.com/v1.0/me/messages?$filter=IsDraft+eq+false+and+ReceivedDateTime+ge+2019-03-28T20%3a08%3a51.929Z+and+ReceivedDateTime+lt+2020-02-20T19%3a48%3a37Z&$orderby=ReceivedDateTime+desc&$expand=SingleValueExtendedProperties(%24filter%3did+eq+%27String+0x7D%27)&$select=conversationId%2cchangeKey%2csentDateTime%2creceivedDateTime%2cisRead%2chasAttachments%2cinternetMessageHeaders%2csender%2cfrom%2ctoRecipients%2cccRecipients%2cbccRecipients%2csubject%2cinternetMessageId%2cparentFolderId&$top=50&$skip=51

在发送更多请求之前等待一个小时似乎没有帮助.看起来问题出在大请求上.

Waiting for an hour before sending more requests doesn't seem to help. It looks like the problem is with the large request.

编辑 #2:有助于减少错误数量的方法是从查询字符串中删除 filter=IsDraft+e​​q+false 部分，并在客户端过滤草稿.我仍然偶尔会收到 503 错误，但要少得多.

Edit #2: Something which helped decrease the number of errors was to remove the filter=IsDraft+eq+false part from the query string, and filter the drafts on the client side. I still get occasional 503 errors, but much less.

推荐答案

这里有关于邮箱限制的具体指南 https://docs.microsoft.com/en-us/graph/throttling#outlook-service-limits 它们基于个人用户邮箱.因此，如果您在 10 分钟内调用超过 10,000 个 API 请求或在超过 4 个并发进程中调用它，您可能会遇到这种情况.

There is specific guidance on Mailbox limits here https://docs.microsoft.com/en-us/graph/throttling#outlook-service-limits They are based on the individual user mailbox. So if you are calling more than 10,000 API requests in a 10 minute period or calling it in more than 4 concurrent processes you may be hitting this.

不过，您没有收到 429 响应，这假设您没有受到服务的限制.

You are not getting a 429 response though, which would assume that you are not being throttled by the service.

所以我更了解你的问题，如果你每 5 分钟运行一次，你为什么要返回整整一年?通过添加该数据范围，这是一个更复杂的查询.您可以使用 Delta 查询来获取草稿文件夹 https://docs.microsoft.com/en-us/graph/delta-query-overview

So I understand your problem more, if you are running this every 5 mins, why are you having to go back a whole year? That is a much more complex query by adding that data range. You could use the Delta queries to just get the changes since the last 5 mins for the Drafts folder https://docs.microsoft.com/en-us/graph/delta-query-overview

这篇关于Microsoft Graph API 返回 503/504 错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！