持续的 Spotify 429 错误 - 带有荒谬的重试建议 76,000 秒（约 21 小时）

Posted 2023-04-15

【中文标题】持续的 Spotify 429 错误 - 带有荒谬的重试建议 76,000 秒（约 21 小时）

【英文标题】：Persistent Spotify 429 errors - with ridiculous retry-after suggestion of 76,000s (about 21hr)

【发布时间】：2022-01-15 13:36:22

【问题描述】：

我正在开发一个应用程序，它使用 Spotify Web API 根据给定的配方（基本上只是一个代表逻辑方案的 JSON）为用户构建和维护播放列表。 当前应用程序处于开发模式。我在每次 API 调用之间使用延迟，目前约为 400 毫秒。当我偶尔遇到 429 错误（请求太多）时，我也有 7.5 秒的延迟。

无论如何，我最近做到了，所有的播放列表配方都在无限循环中重建。因此，该过程始终在运行并大约每 100 毫秒进行一次 API 调用，以便根据配方保持所有播放列表的最新状态。然而，在让这个循环运行大约 10 分钟后，即使在 7.5 秒或更长时间后重试，我也开始持续获得 429 秒。

显然 429 响应包含一个名为“retry-after”的标题，这是 Spotify 建议在拨打另一个电话之前等待多长时间（正如我所说，在我只是在 429 上使用固定的 7.5 秒延迟之前）。我看到我收到的 'retry-after' 价值约为 76,000 秒（21 小时）。

但我认为速率限制是在 30 秒的窗口内强制执行的... （请参阅https://developer.spotify.com/documentation/web-api/guides/rate-limits/）那么为什么我的“重试后”标头如此之高？

这主要是一个设计哲学问题，所以我认为代码本身大部分是无关紧要的，但如果你想看看它可以在这里找到：https://github.com/jakefoglia/Smart-Playlist-Manager

site/SPM-core/maintainer.js : 包含“无限循环”

site/SPM-core/spotify_api_hook.js ：包含大部分 API 调用

【参考方案1】：

文档中的 30s 窗口仅作为示例，而不是 API 的实际工作方式。正如您所说的那样，Retry-After 标头（值是秒）是您决定在进行下一次调用之前等待多长时间所需的所有信息。

每次您的应用通过提早请求“违反”速率限制时，它都会因延迟期延长而受到“惩罚”，而且由于该应用显然从未咨询过标头，并且一再违反限制，因此延迟得到这么高。然而，这并没有导致关闭、阻塞、拒绝或类似情况，因为标头仅建议延迟的持续时间，而不是强制执行。

【讨论】：

好的，我明白你在说什么。我会让它遵守他们的拖延。这对于一个高级项目和网络编程来说对我来说有点新鲜。谢谢你的解释！