@zogstrip 你方便审查这个 PR 吗？鉴于你最近审查了我在这个领域的上一个 PR，应该对相关背景有所了解。FIX: Make migrations from S3 more robust; fix bare URL migration by johnsonm · Pull Request #10093 · discourse/discourse · GitHub
我在其中包含了我在这次相对大规模的迁移过程中所做的修复。我并没有尝试为每个修复都添加测试；我不确定如何注入每种形式的错误。但至少新功能已经过测试。
@RGJ 我认为我目前的 PR 可能已经解决了你提出的前两点以外的所有问题，只是我不确定 CDN 的情况。我的站点使用了 CDN，并迁移了带有 CDN URL 的视频，但这可能是由于 Discourse Spaces 的命名方式导致的副作用。如果你有额外的案例，希望我的 PR 能为你提供一个便捷的脚手架，以便向正则表达式中添加内容并为额外的变体添加测试用例。
我认为首先按帖子进行迁移是正确的，因为在迁移帖子中的上传内容后，需要重新烘焙（rebake）该帖子，以确保生成的帖子中包含正确的 URL。在我完成帖子迁移之后（鉴于我已将速率限制改为直接检查队列长度，现在可能不到两周），我将着手处理任何剩余的清理工作。
由于多个帖子可能引用相同的内容（如果多人上传了同一文件），因此需要进行第二轮检查，查看已烘焙数据中的旧 URL，并重新烘焙这些帖子以获取新位置。这可以使用相同的速率限制机制来避免占用队列。
在 makerforums 上，我可能不会看到任何损坏的标志，因为我们在停止向“s3”（对我们来说是 DigitalOcean Spaces）添加新内容后调整了品牌标识。但我可能会看到至少有一批头像上传内容仍留在 S3 中。迁移与帖子无关的上传内容，应在所有帖子迁移完成后才开始。我可能需要在完成帖子中的上传迁移后，再编写相关说明。
@pfaffman 我看到了 https://meta.discourse.org/t/bizarre-problems-with-migrate-from-s3/86337/5，其中描述了未重复出现的错误。如果没有当前 PR 中的修复，错误会被静默吞掉，包括验证失败。我认为这里的工作至少能解决你当时遇到的部分问题。
@hosna 你在 https://meta.discourse.org/t/what-does-rake-uploads-migrate-from-s3-exactly-do/97285 中提出的问题，在本 PR 中已经得到部分或完全解决。如果尚未完全解决，我已添加了测试，这将使后续添加更多测试以验证其他修复变得更加容易。
@sam 既然你给这个 PR 加上了 2.6 标签，我假设它至少几天内不会被合并；我是否应该将我的速率限制功能工作一并拉入该 PR，与修复内容合并？还是你更倾向于将修复和功能开发放在不同的 PR 中？两种方式我都可以。速率限制功能运行得非常顺利；现在由于我在等待 Sidekiq 队列清空，我的迁移速度提高了约三倍，且未影响站点可用性。因此，如果这通常是 PR 中可接受的内容，我认为将其合并是合理的。否则，我需要等待该 PR 所基于的工作被合并。无论如何，希望能听到你的意见。
..
我已将迁移速率限制补丁进行了 DRY 处理，并将其拉入 PR。实际运行效果良好，sar 数据显示在实时迁移期间，我几乎连续处于零空闲时间状态，同时站点仍保持正常运行。批量模式的一个好处是，我可以在每一批完整的迁移完成后检查是否有新的 Discourse 版本。我在 2.6.0beta1 发布后的第一时间就将站点升级到了该版本，并自更新以来一直在 2.6.0beta1 上成功运行迁移，同时叠加了我的迁移 PR。
我认为该 PR 现在已准备好接受审查；我计划提交另一个 PR 来处理最后几个阶段，但先将这部分内容到位，即使在我完成最后几项工作之前，也能提升所有人的整体迁移体验。