うん、それが問題だと思う。LLM（大規模言語モデル）の推測では、コードがエントリのリストを適切に処理できていないため、500エラーが発生しているらしい。
うーん、つまりこれは Contribute > Bug の範囲に入るってこと？
これはバグだと思いますし、おそらく簡単な修正で済むとは思いますが、新しいカテゴリについては正直よく理解していません。（個人的には、完全に理解できていないと感じるコードは提出したくないです。）
また、データベースの状態が別のバグによって引き起こされている可能性もあり、その場合も修正が必要になるかもしれません。
このトピックへの投稿者は3名のみなので、新しいバグ報告のトピックを立てるのも有効かもしれません。モデレーターがマージやカテゴリ変更を希望すれば、いつでも対応できます。
うーん、実は Contribute > Bug のトピックを見たことがなかったし、記憶をたどってもそこに投稿したことは一度もない。それに、バグかどうかを特定するほどのスキルがあるわけでもない。
それに、そう、たぶん君の言う通りで、過去のDBの問題が原因で、この脆いポイントがトリガーされたのかもしれないね。
管理者アカウントに再びアクセスできるようにする必要があるのは事実だけど、それは早急にとは言え、まあ神の御手次第ってところかな。ただ、少なくとも問題の根本原因にたどり着けたかもしれないから、ここは期待しよう！
助けくれてありがとう。
また、この問題がログイン時に発生することを回避するために、ユーザーアカウントの管理者権限を剥奪し、モデレーターレベルに変更するという提案が妥当かどうか気になっています。
バックアップを取った後に試してみようと思います。
懸念しているのは、データが失われたり、エラーが出なくても確認のしようがない形でシステムが壊れてしまうことです。
どういたしまして。興味深い経験でした。
たぶん、SQLで何か小さなことをすれば重複エントリを削除できるのでしょうが、個人的にはそれを軽率に行うことはしません。
また、LLMによると、Railsコンソールを使って10行のRuby関数を更新し、それを強化することも可能だということです。少なくとも、これは安全な方法であるべきです。再起動すれば、ディスクから本物のRubyが読み込まれ直すからです。
この内容を貼り付けて保存しておきたいです。タブを閉じても残しておけるようにするためです。これはLLMから出力された未テストのコードで、実行中のシステムに対してRailsコンソールで適用するモンキーパッチとして提示されています。また、この脆弱性（＝今回の「oops」の原因）に対するLLMによる修正提案も含まれています。
# CurrentUserSerializerを再オープンして、壊れたメソッドをオーバーライド
# Re-open the CurrentUserSerializer to override the broken method
class CurrentUserSerializer < ApplicationSerializer
def has_new_upcoming_changes
last_visited = object.custom_fields["last_visited_upcoming_changes_at"]
# プリローダーによって配列としてキャッシュされている場合、文字列を抽出
# Extract string if cached as an array by the preloader
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分放置した（サーバーはログイン時に負荷上昇を示していた）が、依然として何も進まない
- しかし「アクティブ」ユーザータブには、当該ユーザーがX分前にログイン済みと表示されている
- 別の（プライベート）ウィンドウで2回目のログインを試みると成功した！
つまり、これはメッセージやチャットなどを閲覧する必要がある管理者ユーザー向けの回避策としては機能しますが、根本的な問題は解決していません。
次に、別の管理者アカウントから、ログイン済みの元管理者ユーザーアカウントに「管理者権限を付与」する
- ログイン中に、管理者権限の更新に成功したことを示すメッセージが届く。
- ページをリロードすると、また同じエラーが表示される
9月28日にクローズされた「Git hang」トピックに投稿することはできませんが、数分前に動作が鈍くなっているのに気づいたとき、「ああ、またGitが止まって問題を引き起こしているのか」と思いました。すると、まさにその頃、downdetector.comにはGitHubの大規模な障害のスパイクが表示されていました。