Microsoft Graph API 返回 503/504 错误答案

【问题标题】：Microsoft Graph API returning 503/504 errorsMicrosoft Graph API 返回 503/504 错误
【发布时间】：2020-03-30 15:15:49
【问题描述】：

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

有时我会收到 503 Service Unavailable / 504 Gateway Timeout。一旦发生这种情况，请求将无法继续，并将继续遇到这些错误。

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

我想知道一年的查询是否太多，即使有分页？除了后退之外，还有什么解决方案的想法，以及时长？

谢谢

失败的示例查询：

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

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

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

【问题讨论】：

标签： office365 microsoft-graph-api outlook-restapi microsoft-graph-mail

【解决方案1】：

您是否尝试过更改过滤器语句的顺序？在您的情况下，我会先按日期过滤，然后过滤掉所有邮件，即草稿：

https://graph.microsoft.com/v1.0/me/messages?$filter=ReceivedDateTime+ge+2019-03-28T20%3a08%3a51.929Z+and+ReceivedDateTime+lt+2020-02-20T19%3a48%3a37Z+and+IsDraft+eq+false&$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

我在使用 MS Graph 时遇到了一些限制问题，我可以通过更改过滤器语句的顺序来解决这些问题。在一个有十年历史的邮箱中，可能比过去两年的邮件更多，而不是草稿。我总是尝试先应用较窄的过滤器。

【讨论】：

感谢您的回答！一个非常有趣的想法。我试过了，遇到这个问题的邮箱仍然会出现同样的错误，可能是那些在分页响应时有更多电子邮件要迭代的邮箱。
是否可以在晚上运行应用程序？节流限制取决于服务器负载，并且在晚上 8 点到早上 6 点之间高达 5 倍，因为没有太多的用户交互。如果缺少 Retry-After 标头，还请考虑文档docs.microsoft.com/en-us/graph/throttling 的这一部分中关于实施指数退避重试策略的注释。如果您提供了有关您的目标的更多信息，它也可能会有所帮助。也许有更好的方法来实现它，例如使用增量查询。
抱歉回复晚了，再次感谢大家的回答。它实际上已经在非工作时间运行。我确实尝试后退一个小时而没有任何变化，这似乎是节流以外的其他东西。最终目标是导入一年内的整个邮件历史记录。
我们有类似的情况，这个简单的查询 GET /me/messages?$filter=(lastModifiedDateTime ge 2020-07-23T13:17:29Z) 永远不会成功！只有使时间戳更接近现在才能解决问题，但我们希望能够获取自特定日期以来的所有消息。

【解决方案2】：

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

您没有收到 429 响应，这将假定您没有受到服务的限制。

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

的更改

【讨论】：

感谢您的回复。我将更彻底地研究增量查询。目的是对一年前的电子邮件执行一次导入。我发布的 URL 是从上一个请求中作为 nextLink 返回的 URL，我们正在迭代这些链接，而不是每次都重新启动查询。 isDraft 设置为 false，我们正在获取常规电子邮件。实际上，它看起来不像是节流，而更像是服务器在为响应分页数据时遇到的一些问题或延迟。不是应该能应付吗？我应该提到它通常可以顺利运行，但对于某些邮箱我会收到此错误。
再澄清一下 - 它不是每 5 分钟运行一次相同的请求，其想法是每 x 分钟拉几页，然后停止直到下一个“作业”，这将继续前一个一个离开了。通过从响应中获取 nextLink 来完成页面的前进。