是的，我认为这就是问题所在。大语言模型认为代码没有很好地处理条目列表，因此导致了 500 错误。
好的，那我们是不是该去 Contribute > Bug 频道了？
我认为这是一个 bug，而且修复起来应该很简单，但我对新的分类机制并不太了解。（而且，如果我觉得自己还没有完全理解，我个人是不会提交代码的。）
另外，还有一个问题是：你的数据库的状态是否是由另一个同样需要修复的 bug 导致的？
由于这个主题目前只有三位参与者，或许可以新开一个 bug 报告主题——如果版主希望合并或重新分类，他们随时都可以这样做。
好吧，我其实没注意到 Contribute > Bug 这个话题，据我所记，我也从没在里面发过帖，而且我的技术水平也不足以判断这到底是不是 bug。
而且，没错，你说得可能对，确实可能存在一些历史遗留的数据库问题，触发了这个脆弱的环节。
虽然我们需要尽快恢复管理员账号的访问权限，但这件事恐怕还得听天由命。不过至少我们可能已经找到了问题的根源，那就只能祈祷了！
谢谢你的帮助。
另外，我也在想，如果把用户的账号从管理员权限降级为普通版主权限，是不是就能绕过登录时出现的这个问题？
我可能会先备份数据，然后再试试看。
我担心的是数据丢失，或者弄坏了一些东西，而我又完全不知道该怎么检查——万一表面上看起来一切正常，也没有报错的话。
不客气。这个过程挺有意思的。
也许你可以用 SQL 做点小改动来删除那条重复记录，但我个人不会轻易这么做。
另外，根据大语言模型的说法，你也可以使用 Rails 控制台来更新那个十行的 Ruby 函数，从而增强其健壮性。至少这应该是安全的，因为重启服务时会从磁盘重新加载真正的 Ruby 代码。
我想粘贴以下内容以保留它，这样我就可以关闭这个标签页了——这是一段来自 LLM 的未经测试的代码，在这里以猴子补丁（monkey patch）的形式呈现，用于在 Rails 控制台中应用到正在运行的系统上。其中还包含一个由 LLM 建议的修复方案，旨在解决导致该错误的脆弱性问题：
# 重新打开 CurrentUserSerializer 以覆盖损坏的方法
class CurrentUserSerializer < ApplicationSerializer
def has_new_upcoming_changes
last_visited = object.custom_fields["last_visited_upcoming_changes_at"]
# 如果预加载器将其缓存为数组，则提取字符串
last_visited = last_visited.first if last_visited.is_a?(Array)
return false if last_visited.blank? && object.created_at < Discourse.site_creation_date + 1.hour
cutoff = last_visited.present? ? Time.zone.parse(last_visited.to_s) : object.created_at
UpcomingChangeEvent.added.not_backfilled.where("created_at > ?", cutoff).exists?
end
end
撤销管理员权限
以下操作针对最初被锁定管理权限的用户账户：
-
撤销管理员权限 + 授予版主权限 = 登录失败/出现相同错误。
-
撤销版主权限
- 首次登录（无错误）但卡在两步验证/登录加载转圈界面
- 等待了约 10 分钟（服务器显示登录时负载有所上升），仍然没有反应
- 然而“活跃”用户标签页显示该用户已在 Xm 前登录，嗯
- 尝试在另一个（隐私）窗口进行第二次登录，这次成功了！
好的，这可以作为管理员用户需要读取消息/聊天等内容的临时解决方案，但并未从根本上解决问题。
接下来，使用另一个管理员账户向已登录的前管理员用户账户 授予管理员权限
- 在登录状态下，收到管理员权限更新成功的消息。
- 刷新页面，哎呀，错误再次出现
我无法在 “Git hang” 这个主题中发帖，因为它从9月28日起已经关闭了。不过，几分钟前我注意到一些卡顿现象时，心想：噢，也许 git 又出问题了，正在导致故障，结果不出所料，downdetector.com 几乎就在那个时刻显示了 GitHub 的一次大规模服务中断峰值。