はい、ユーザーが削除されると、そのユーザーが RSVP したイベントから削除されます。もしかすると、そのコードが原因かもしれません。
「いいね！」 3
エラーに含まれるすべてのトピックIDが、イベントを使用しているトピックだからです。
ふむ、私が削除しているこれらの特定のユーザーは、参加表明（RSVP）をしていないはずです。ただし、参加表明（RSVP）が有効になっているトピックがこれらだけなのかもしれませんね。
「いいね！」 3
ああ、わかりました。
@fzngagan これ、安全でない .find( を使っていますね？
topics = Topic.find(topic_ids) if topic_ids
先ほど Follow にプッシュした 修正 をご覧ください（ただし、ここでは複数の ID があるため、where を使う必要があるかもしれません）。
「いいね！」 3
更新しましたが、まだ404エラーになります。
「いいね！」 1
バート、@fzngagan が適用して修正を確認するまで待ってください。
「いいね！」 5
修正をプッシュしました。これで問題が解決するはずです。ご確認ください。
「いいね！」 5
これで直りました、ありがとうございます!!
「いいね！」 6
レビューキューに「新規ユーザーが最初の投稿を異常に速く入力した」という理由で複数の投稿が何度も現れるのを目にしています。
詳しく確認したところ、それらの投稿には監視ワードが含まれていましたが、レビューキューにはその旨が記載されていませんでした。
「新規ユーザーが最初の投稿を異常に速く入力した」というフラグは96%の確率で誤りであり、「監視ワード」によるフラグは100%正確です。つまり、監視ワードによりレビューキューに入った投稿は、必ず注意を要する投稿です。そのため、「監視ワード」によるフラグは「新規ユーザーの入力が速すぎる」フラグよりも優先されるべきだと考えます。
以下の状況を想像してみてください。
- 「新規ユーザーが最初の投稿を異常に速く入力した」という理由で投稿がレビューキューに入る。この投稿には「監視ワード」リストにある不可視スパムリンクが含まれている。→ 誰も不可視リンクに気づかない（例：「.」の背後にリンクがある場合など）ため、投稿が承認される。→ 失敗！
- 「監視ワード」が「入力速度が速すぎる」より優先されるため、監視ワードにより投稿がレビューキューに入る。この投稿には「監視ワード」リストにある不可視スパムリンクが含まれている。→ 投稿が却下され、スパマーが「監視ワード」により削除される。→ 勝利！
「いいね！」 5
その通りです。これは境界線上のバグです。eviltrout さん、これを誰かのタスクリストに追加してもらえませんか？Roman さんがまだ担当になっているので、彼に任せてはどうでしょうか？
「いいね！」 4
「いいね！」 8
2.6.0.beta2 版での話です。念のためお知らせしますが、削除されたと思われるトピックがレビューキューに並んでいるようです。おそらく以下のような流れで発生しているのだと思います：
- ユーザーの投稿が早口入力などの理由でレビューキューに追加される。
- そのユーザーがトピックを削除する（もし可能であれば）。おそらく再提出するためだろう。
これが意図された動作かどうかはわかりません。レビューキューではタイトルが空白ですが、投稿本文は表示されており、そのユーザーは沈黙処分されています。ユーザーの公開プロフィールには、トピックや投稿は一切表示されていません。
上記とは無関係です。 フィルターオプションに関する提案があります。個人的には非常に素晴らしい機能だと思うのですが、投稿タイプやトピックタイプに対してより詳細なフィルターを設けることです。現在の「タイプ」のフィルターは以下のようになっています：
「フラグ付き投稿」と「キューイング済み投稿」には、トピックと投稿の両方が含まれています。これを以下のように変更すると非常に便利だと思います：
レビュータイプ：
- フラグ付き
- キューイング済み
さらに、「フラグ付き」を「ユーザーによるフラグ」と「システムによるフラグ」に分割することも検討してもよいかもしれません。
そして、コンテンツタイプ用の別のフィルターも追加します。
コンテンツタイプ：
- トピック
- 投稿
- ユーザー
これは非常に役立つと思います。例えば、投稿や返信の承認よりもトピックの承認を優先したい場合、この機能があれば迅速に対応できます。現在のフィルターでは、「トピックごとにグループ化」以外に、トピックと投稿を区別する方法はありません。
もう一つの提案として、レビューキューの UI を調整し、トピックと投稿の区別をより容易にすることです。現在、この情報は小さなグレーのテキスト（例：キューイング済み投稿、キューイング済みトピック、フラグ付き投稿、フラグ付きトピック）として表示されています。文字サイズは、トピックや投稿のカテゴリやタグと同じサイズです。
私にとって、アイテムがトピックなのか投稿（返信）なのかは直感的にわかりにくく、頻繁に混同してしまいます。
いくつかのアイデア：
- 投稿アイテムの「トピックタイトル」セクションを調整し、返信アイコン を追加する。トピックアイテムよりも小さくし、テキストとして「RE:」を含める。
- アイテムタイプ（トピック/投稿）の文字サイズや強調表示を強化する。
「いいね！」 2
トピックや投稿の承認を試みると、500 エラーが発生します。現在 2.6.0.beta3 を使用しています。ログは以下の通りです：
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
参考になるかもしれない情報として、以前 Akismet をインストールしていたが、現在は削除しました（rake タスクも実行済み）。詳細は以下を参照してください：Feedback on the new Review Queue (2019) - #210 by markersocial
対象のアイテムは過去 60 日以内のもの（auto_handle_queued_age: 60）です。古い投稿（約 2 ヶ月前）と最近のもの（過去 3 時間以内）の両方で試しました。
ユーザーの承認（タイプ：User）はでき、キューに入っているトピックや投稿の「ユーザー削除」オプションも機能しています。
「いいね！」 2
@Roman、これは本当に奇妙ですね。どうしてここで巨大な整数が取得されているのでしょうか？
「いいね！」 6
通知の作成時にエラーが発生しました：
おそらく、何らかの ID を int 型で保存しているのではないかと推測します。Rails は 5.1 から主キーに BIGINT(8) を使用し始めました。
@markersorcial 以下のクエリ結果を共有していただけますか？
Notification.count
User.count
Topic.count
「いいね！」 4
ご確認いただきありがとうございます 
はい、クエリ結果は以下の通りです：
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
「いいね！」 3
更新：Sidekiq を確認すると、このエラーと類似した失敗したタスクが多数見つかりました：
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
これまでに確認したタスクタイプは以下の通りです：
Jobs::PostAlert（最も一般的）
Jobs::ProcessPost
Jobs::NotifyCategoryChange
「いいね！」 1
それらの数値はいずれも最大サイズを超えてはいけません。何か別のものが整数値を上書きしているのかもしれませんね、@Roman さん。
「いいね！」 3
それなら、何か別の問題があるはずです。明らかに何かが起きており、レビューキューに特有の問題ではありません。
これらのジョブは通知を作成しますが、これも失敗しています：
また、以下のような処理を試みると：
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
別のエラーが発生します：
ActiveModel::RangeError: 1311344111111 は ActiveModel::Type::Integer（4 バイト制限）の範囲外です
以下の処理でも同じエラーが発生します：
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
「いいね！」 6
@markersocial エラーについてより詳しい情報が得られるか、PostgreSQL のログを確認できないでしょうか？確認をお願いします。
ログの場所がわからない場合は、こちらをご覧ください：
「いいね！」 5
当社のモデレーターは、フラグ付き投稿を相互に容易に議論でき、その履歴がレビューキューに維持される機能に感謝しています。同じ機能をキューイング済み投稿にも追加することは可能でしょうか？私たちは、新規ユーザーの最初の5投稿を承認が必要とするよう、approve_post_count 設定を使用しています。これらの最初の5投稿はキューイング済み投稿となりますが、モデレーターによる議論が必要な場合、PM（プライベートメッセージ）を開始する必要があります。これではレビューキューから切り離され、履歴が失われてしまいます。
「いいね！」 3