one our badge pages を見ると、
という表示があり、気になりました。これらすべてのアバターには何があったのでしょうか？
実は、これらのユーザーは存在しないことがわかりました。
存在しなくなったユーザーにバッジを付与するのは避けるべきではないでしょうか？あるいは、表示自体を制限するべきかもしれません。いずれにせよ、これらは「本当のユーザー」、つまり私たちが大切にしているユーザーのアバターを追い出しています！
「いいね！」 10
Hmm… ここは何かがおかしいようです。なぜなら：
grant はすでに user と結合しており、どこかから user id を取得する必要があります。
このスコープの付け方が、dependent destroy が正しく機能していない原因ではないかと疑われます。
いずれにせよ、週次のクリーンアップを追加することはできます。
「いいね！」 1
これらのバッジが付与された時期（執筆時点では最も新しいもの）を考えると、ユーザーアカウントが存在しない段階で付与されている可能性が高いです。つまり、アカウントが存在した状態で付与された後に、アカウント削除時に削除されなかったのではなく、最初からアカウントが存在しない状態で付与されたものではないかと推測します。
確認してみます。
「いいね！」 2
奇妙なのは、行にユーザーIDが含まれていることです。ユーザーが削除されると、これらのIDを取得する場所がなくなります。
「いいね！」 3
ユーザーIDは incoming_links テーブルに格納されていると思います。それらのレコードは従属的に破棄されず、共有バッジのクエリは incoming_links テーブルでの user_id が null になることのみを防いでいます：
https://github.com/discourse/discourse/blob/main/lib/badge_queries.rb#L199
First Share バッジにも同様のバグがあるはずです：
https://github.com/discourse/discourse/blob/main/lib/badge_queries.rb#L64
「いいね！」 3
バッジクエリをユーザーテーブルに結合するプルリクエストを作成しました。初めてのプルリクエストなので、すべて正しくできていることを願っています！
「いいね！」 3