我们使用 rss-polling 插件从数十个提要中导入条目。有时，一些提要会从列表中消失。我们不知道在什么条件下，我们不知道如何，也找不到任何此类操作的日志。我们也找不到任何模式。它们只是消失了，我们需要重新创建它们的新条目（当我们意识到它们已经消失时，这对于这么多提要来说并非易事）。
代码中是否有在特定条件下删除 RSS 提要的功能？是否有记录此情况的日志？
去年 @blake 将后端存储迁移到了数据库。
我认为现在只有一个地方会清除 feeds，那就是更新：
特别是如果“feed_settings”被设置为 nothing，那么可能有人工介入？
这种情况发生过多少次？
不过，无论如何，这次更新有点冒险，因为它试图一次性更新所有内容，而不是进行增量更新。
这会不会是你的某个自动化程序发送了一个 []（空值）而不是在更新 feeds 时发送整个状态？
3 个赞
我们唯一使用 RSS Feed 的方式是在 /admin/plugins/rss_polling上手动创建新的 Feed。除此之外别无他用。
我注意到该页面上的 RSS Feed 顺序会不时变化，这已经很奇怪了，而且它无助于调试问题，因为 Feed 创建的按时间顺序被丢失了，而且新的排序似乎不遵循任何字母或数字排序。
我们不知道这个问题发生的频率，因为当它发生时我们无法立即检测到。在最好的情况下，我们只能等待 Feed 的所有者告诉我们新的条目没有出现，或者我们自己意识到，比如说，一个每周播出的播客最近在论坛上没有动静。
我感觉这个问题可能与 CPU 接近 100% 的情况有关，或者服务器上的其他东西达到了最大容量。即使调度程序在一次只轮询 5 个 Feed 方面做得很好，在托管分析中我们也可以看到，当 RSS Feed 被更新时，CPU 基本上达到了 100%。
也许这就是为什么只有几个 Feed 的论坛没有注意到它，但如果你添加了很多，有什么东西可能会偶尔中断，而与调度程序无关？
请参阅相关内容：Are there any upper limits to the RSS Polling plugin? - #4 by icaria36
3 个赞
（进一步思考）
无论如何，我想知道 Discourse 为什么首先要删除 RSS 订阅源，并且是静默删除。如果某个 RSS 订阅源因某种原因有问题，它可以跳过这一次并记录问题。从这一点来看，可能会发生两件事：
- 这是一个偶发性问题，下一次计划任务运行将正常工作。日志条目将被遗忘。
- 问题持续存在，每一次跳过都会在错误日志中留下条目，当有人意识到有问题时，管理员可以检查错误日志并找到详细信息。
理想情况下，管理员会收到某种通知，但我理解这可能会为潜在的解决方案增加额外的工作。跳过而不是删除 + 错误日志条目本身就已经是一个很大的改进了。
并且解释一下这个问题对我们项目的影响。我们有一个独立的播客门户，他们联系我们进行聚合，我们创建一个频道（子类别）来导入他们的节目，听众可以在其中点赞和评论……当他们发现我们停止聚合他们的节目，而我们不得不告诉他们他们的订阅源不知何故被删除了时，这给我们的项目和 Discourse 平台留下了非常糟糕的印象……
1 个赞
这个“临时”代码已经存在一年多了，很可能是罪魁祸首。我来看看。
5 个赞
我们先从这个修复开始。我并不是说这是供稿被神秘删除的原因，但至少在实际删除供稿之前添加一个确认对话框是一个开始。
我以后有更多时间再进行改进。我想添加一个合适的编辑/保存单个供稿的用户界面，而不是每次编辑时都只更新/保存所有供稿。
@icaria36 如果你更新了你的插件，你将获得这个最新更改。当我有更多改进准备好时，我会再次跟进。
3 个赞
感谢您的补丁！我立即升级到了新版本，并添加了缺失的 RSS 源（大约 20 个！），今天我检查了一下……源又被默默地删除了。 
我不知道什么时候，我不知道怎么做，我仍然不知道是哪些，但大约有十几个不见了。我没有看到任何对话框询问有关源的问题，或者任何其他信息。此外，我还注意到了在服务器 CPU 正常时重新添加 RSS 源，避免了 RSS 轮询时间，以排除这个因素。
我有一种感觉，列表排序发生变化的事实与源消失的事实之间存在联系。无论是什么导致排序发生变化，都可能足够“创伤性”，以至于也会造成损失。一个有用问题可能是：列表排序为什么会首先改变？源消失而列表排序保持不变同样糟糕，但感觉会……更“干净”。 
从我们这边修复这个问题很麻烦（在源的所有者注意到并询问之前找出哪些源丢失了 + 重新添加源条目），但检测它更麻烦，因为唯一的方法是逐个检查类别-源，看看哪些丢失了——或者至少手动计算上次计数时有多少源。
为了节省调试时间，可以在 /admin/plugins/rss_polling 中显示一个显示源总数的字符串，即“N 个源”。并且/或者让列表编号。
1 个赞
啊，真糟糕，我猜也是这样，不过还是谢谢你告知最新情况。现在假期结束了，我会着手对此进行妥善修复。
1 个赞
我通过最新的更改大大改进了管理员用户界面，应该可以解决 RSS feed 被神秘删除的问题。
现在有了单独的创建、更新和删除逻辑，而不是在修改任何内容时都尝试更新所有 feed。现在应该能更好地工作了。
2 个赞
非常感谢您的迅速行动！我今晚将进行升级，确保我们启用了所有 feed，并在此处报告任何问题（希望不会有任何问题！）。
1 个赞
太棒了，这改进太大了！每个订阅源都单独编辑，一次保存一个更改。保存新订阅源是即时操作。以前，当您有很多订阅源时，添加新订阅源并按保存图标意味着在整个列表刷新之前需要几秒钟的处理时间。现在感觉稳定可靠。非常感谢！
我会等几周，以验证没有订阅源丢失。
有几个关于改进用户界面的建议，以防它们有用且时机合适：
用于添加新订阅源的“+”按钮在顶部，但新行却添加在底部。如果订阅源列表长于屏幕，用户会点击“+”但看不到任何反应。我很熟悉这个页面，一开始我以为按钮坏了。然后我检查了列表的末尾，发现那里有一行新的，等待着，就像以前一样。
- 将新行添加到列表的开头，就在“+”按钮下方，可能是一个不错的选择。如果这样可以将新订阅源放在调度器的最前面，那也很好。新订阅源比已建立的订阅源更有可能带来更多的工作和需要检查的事项。
有两个字符串“Feed Settings”和“Discourse Settings”似乎孤零零地挂在那里。“Feed Settings”似乎是多余的，因为列表就在下方并且不言自明。“Discourse Settings”是链接到 /admin/site_settings/category/plugins?filter=plugin%3Adiscourse-rss-polling 吗？或者它们应该是两个不同子页面的选项卡？
- 一个替代方案是直接删除它们。
2 个赞
太棒了！
是的，你说得对。我会记住这一点。我们有一个关于 Creating consistent admin interfaces 的新话题，我认为一些改进会从 rss-polling 插件中慢慢渗透出来。我猜我们可能会创建一个单独的编辑屏幕，就像我们为其他插件做的那样，而不是进行内联编辑。
是的，谢谢你指出这一点。我明白这有多令人困惑。“Feed Settings”是前两列的标签，表明这些列会影响 RSS Feed。“Discourse Settings”标签是为最后三列设置的，表明当你修改它们时，它们会影响 Discourse 中的内容。
3 个赞
一周过去了，我们在原有的百余个 RSS 源的基础上又添加了数十个，列表现在非常稳定。我们没有发现任何问题！
3 个赞
此主题在 36 天后自动关闭。不再允许回复。