デフォルトのウォッチが大量のメールをトリガー - default_watch_categories

バグ
1

3.1.0.beta5 - [09feb03056]

default_watch_categories がデフォルト（何も設定されていないはず）から単一のカテゴリに設定されました。これはおそらく史上初のことです。

これにより大量のメールが送信され、3日間で約40万件のメール再試行が処理された可能性があり、そのうち09%が失敗しました。ごく初期の段階で、これがSMTPプロバイダー側のレート制限を引き起こしました（これにより、意図しない莫大なメール料金請求が回避されました！）。

default_watch_categories 設定は、誤って設定されたため、リセットされました。

しかし、SMTPプロバイダーのレート制限がまだ有効であったため、Sidekiqでは依然として大量のメール再試行が表示されており、失敗し続けながらも試行を繰り返していました。

詳しく調べると、default_watch_categories がデフォルトにリセットされたにもかかわらず、1つの投稿が同じメールを何度も繰り返しトリガーし、数百、そして数千回も再試行しているように見えました。一体何が起こっていたのでしょうか？

その投稿と、それ以下の投稿が、通常のモデレーション上の理由で独自の「新しい」トピックに分割されたところ、ボーナスとしてメールトリガーと再試行が完全に停止しました。もう再試行はありません。

SMTPプロバイダーのレート制限に感謝！

2

追加の洞察として、これはSMTPプロバイダーの制限により、失敗したときにのみ検出されました。ダッシュボードに、過去7日間、24時間、および1時間のメール送信アクティビティのより明確な表示と、急増に対するアラートがあれば歓迎されるかもしれません。

このようなことは、経済的に大きな問題を引き起こす可能性があります。

プロバイダーがレート制限を導入しなければ、これは数日で年間ホスティング費用を使い果たしていた可能性があります！:crazy_face:

4

Hey @agemo

あなたのインスタンスでこのサイト設定を確認していただけますか？

admin setting
admin setting2214×434 44 KB

これはユーザーのデフォルト設定です。ユーザーはプロフィールでこれを上書きできます。

user setting
user setting1312×984 85.6 KB

考えられる原因は以下の通りです。

  1. デフォルト設定が「常に」または「不在時のみ」になっている。
  2. ウォッチ対象カテゴリでトピックが作成された。システムは全ユーザー/不在ユーザーに通知しようとした。
  3. レート制限によりクラッシュするSidekiqジョブが多数キューイングされた。
  4. デフォルトのウォッチ対象カテゴリが削除されたが、既にキューイングされたSidekiqジョブは削除されていない。
  5. Sidekiqは失敗したジョブをリトライする。
  6. 投稿が新しいトピックに移動された際、以前に誤って作成された通知は削除された。
  7. 通知が削除された際、リトライジョブはメールを送信せずに正常に完了した。
「いいね！」 3
5

default_email_level : 離席時のみ

deafult_email_message_level : 無効

「いいね！」 1