tl;dr 我想补充一点，我们这里似乎遇到了相同的问题。如果由于最近的某些变更导致存在速率限制问题，那么我认为其他用户在迁移、重新烘焙帖子时，或者仅仅因为论坛非常繁忙时，也会开始遇到这个问题。事实是，onebox 看似静默失败，这意味着这些问题直到用户开始抱怨缺少 YouTube onebox 时才会显现出来。
背景
我们当前使用的是 2.6.0.beta 1 版本。
用户收到了关于非安全内容的警告。经过调查，Chrome 似乎在抱怨来自 HTTP 站点链接的图片。因此，我将 Discourse 配置为下载所有图片/媒体并通过 HTTPS 提供服务。
更改该设置后，这意味着需要对历史帖子进行重新烘焙。自那次重新烘焙以来，之前被 onebox 化的大量 YouTube 视频现在又变回了链接 URL。
我们有一个包含 10,000 条回复的线程，其中全是 YouTube 视频回复，且所有帖子都显示为 URL 而非 onebox。
在重新烘焙过程中，所有排队作业都正常处理，因此并非有作业卡在已删除作业的队列中。
我没有看到 @marcozambi 描述的那些错误消息，但我相信我们也触发了速率限制。
我已尝试过的方法
为了支持这一速率限制理论，我编写了一段小程序来重新烘焙帖子，该程序在某个线程的前 80 多个 YouTube 视频中成功实现了 onebox 化，但随后无法转换剩余的視頻。
此时，即使编辑帖子、进行小幅修改并重新保存，也无法强制 URL 被 onebox“展开”。与此同时，所有队列均为空，或者正如我所预期的那样，只有少量作业被即时处理。
在 30 分钟内多次尝试重新运行该代码，均无法强制对这些链接进行 onebox 化。我认为 80 并非一个神奇的数字，这只是我们可用配额所能支持的数量。
@marcozambi 提到，当其他链接失败时，使用 /embed/ 格式的 YouTube 链接可以正常工作，因此我修改了代码，使用正则表达式搜索并替换 YouTube 链接，将其转换为 /embed/ 格式。
代码生效了。
但再次运行代码仅重新烘焙帖子时，却无法将其转换为 onebox 表示形式。
我的计划是尝试创建一个任务，将大型线程中的所有 YouTube 链接转换为 /embed/ YouTube 格式。如果该方案失败或我们触发了更高的速率限制，我将查看 @merefield 的 Onebox Assistant。
我稍后会发布更新。