数日前からのアップデートで深刻なメール問題が発生 - 3.4.0.beta4-dev

サポート
1

数日前にDiscourseを最後に更新してから、返信メールが機能しなくなり、受信されず、トピックが更新されないようです。また、監視対象カテゴリの送信済みメールも誤作動しており、65件中5件しか送信されていません。

最近、メールの問題を経験した方はいらっしゃいますか？

「いいね！」 2
2

はい、残念ながら3.4.0.beta4-devでも同様の問題が発生しています。app.ymlファイルの再評価やメールDNS設定の確認など、あらゆることを試しました。皮肉なことに、ターミナルからはwasmを使用してDiscourse Dockerコンテナ内でsmtp経由で送信することができました。これは、どこかに設定バグがあることに起因している可能性があります。これは、投稿、ニュースレター、パスワードリセットのメールを受信できない登録済みユーザー全員にとって大きな問題です。550 ERRメッセージは、新しいアップデート以来続いています。今、v3.4.0.beta2にロールバックすればこのバグが解決することを祈っています。

「いいね！」 1
3

自分だけじゃないとわかって嬉しいです。開発者の方がこの問題をできるだけ早く修正してくれることを願っています。ロールバックの方法がわかりません。

インストール済み
3.4.0.beta4-dev
58f75ed205

4

同時にPostgreSQLデータベースの13から15へのアップデートも行われました。

5

GUI の設定が postgres のアップデートで壊れたのかどうか分かりません。POP3 サーバー情報をポーリング用に設定しても、app.yml discourse の設定ファイルに何も変更が加えられなかったためです。非常に奇妙です。ロールバックは、git タグに入ってバージョンからアプリ全体を再構築する必要があるため、少しトリッキーです。これをトラブルシューティングするには ChatGPT を使用すると役立ちます。

6

バージョンをロールバックして動作しましたか？

開発チームがすぐにこれに取り組み、前方修正を作成してくれることを願っています。

7

Dockerで git checkout v3.4.0.beta2 を試しましたが、app.yml ファイルを指定しても複数回ロールバックに失敗しました。そのため、まもなく beta5 の 550 エラーバグを修正するために、Discourse の担当者に連絡できるか確認します。

8

このエラーはどこで確認できますか？メールで大きな問題が発生していますが、550 errをどこで確認すればよいかわかりません。ありがとうございます。

GUI経由のメールログにはエラーが表示されていませんが、返信が受信されず、送信メールも約65人に送信されるべきところ、数人にしか届きません。

9

/logs で以下を確認しました。

image

11

チームメンバーを@メンションしないでください。

Discourseの有料顧客であれば、team@discourse.orgに連絡することで優先サポートを受けることができます。それ以外の場合は、ベストエフォートとなります。

報告する際は、使用しているメールプロバイダーを指定してください。Discourseで一般的に使用されているメールプロバイダーで何かが後退した可能性があります。わかりません。

「いいね！」 3
12

申し訳ありません、気づきませんでした。二度とそのようなことはしません。メンションについてご指摘いただきありがとうございます。

13

Brevoを使用していますが、見ている限りではBrevoとは関係ないと思います。一部のメールは送信されているからです。
返信はGmail経由で届いていますが、それは常に機能していました。
おそらく、他の回答者が何を使用しているか教えてくれるでしょう。彼は同じ問題を抱えています。

14

サーバーログとレポートの下にあります。テストメールを送信でき、スキップタブに550メールエラーが返されます。開発者からは何も聞いていません。PostGres 15のアップデートでも、app.ymlが通信を必要とする場合に設定がdbに転送されず実行されない可能性があると思います。

15

テストメールは正常に送信でき、エラーもありません。そのテストメールはBrevo経由で送信されます。

問題は、監視カテゴリのメールが一部のユーザーにしか送信されないことです。送信されなかったメールはスキップされたものとして表示されません。ほとんどのユーザーにはメールが送信されません。

2つ目の問題は、返信メールがシステムに届かないことです。

これらの問題は、最近のアップグレード後にのみ発生しています。

16

Ubuntu 22.04 を使用しています。こちらも最近コンテナのアップグレードがありましたが、ディスコースをアップグレードした後、Postgres もアップグレードされましたが、メールの問題には気づきませんでした。

Phil はどのオペレーティングシステムを使用していますか？

17

本番ログにこれが頻繁に表示されます。

Email can not be processed: Email::Receiver::EmptyEmailError

tail -1000 production.log-20250202 | grep ‘Email::Receiver::EmptyEmailError’ | wc -l
291

このトピックを見ましたが、解決策が理解できません。誰か説明してもらえませんか？受信トレイはどこにありますか？メッセージをアカウントに対して2回クリックすると受信トレイが表示され、それらのメッセージを削除できますが、それほど多くはありません。つまり、すべての受信した返信メール、どの受信トレイなどをどのように確認すればよいですか？

18

エラーをクリックすると、詳細が表示されますか？メールのフォーマットが異常に悪い単一のメールである可能性があり、それを処理するジョブを繰り返し再スケジュールしています。

「いいね！」 1
19

トピックに投稿したところ、65件のメールが作成されるはずが、送信済みには5件しか作成されず、スキップなどもありませんでした。エラーも警告もありません。

昨日から /logs にエラーが1件と警告が1件ありますが、メールの問題と関係があるかは不明です。

Message (552 copies reported)

Job exception: Net::ReadTimeout

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:229:in `rbuf_fill'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:199:in `readuntil'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:377:in `each_message_chunk'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:958:in `block in retr'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:1016:in `critical'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:956:in `retr'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:810:in `pop'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:47:in `block (2 levels) in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:46:in `block in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:45:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/app/jobs/base.rb:379:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:137:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:77:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:63:in `block (2 levels) in ensure_worker_threads'


Message (694 copies reported)

Email can not be processed: Email::Receiver::EmptyEmailError


Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `block in warn'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `warn'
/var/www/discourse/lib/email/processor.rb:183:in `log_email_process_failure'
/var/www/discourse/lib/email/processor.rb:29:in `rescue in process!'
/var/www/discourse/lib/email/processor.rb:16:in `process!'
/var/www/discourse/lib/email/processor.rb:13:in `process!'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:29:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:49:in `block (2 levels) in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:46:in `block in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:45:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/app/jobs/base.rb:379:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:137:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:77:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:63:in `block (2 levels) in ensure_worker_threads'
20

【quote=“sandra.mccollum, post:19, topic:350165”]
私はちょうど65通のメールを作成するはずのトピックに投稿しましたが、実際には送信済みに5通しか作成されておらず、スキップされたものやエラー、警告もありません。
[/quote]

どうして、65通のメールを作成するはずだとわかるのですか？

「いいね！」 1
21

正確にどのユーザーが「視聴済みカテゴリ」を設定しているか、そしてこれが「視聴済みカテゴリ」であり、ユーザーが通知をミュートしていないことを把握しています。アップデート前は常に65件のメールが送信されていたはずなので、今回も送信されるべきです。

本日中に新しいリリースにアップデートして、違いがあるか確認します。バージョンは3.4.0.beta4-devから新しいバージョンになります。

VMを再起動します。これによりデータベースが正常に再起動されるはずです。ちなみに、3.4.0.beta4-devへのアップデート時にドキュメント通りにインストールは正常に行われました。

Ubuntu22.04 O/Sのcontainerdへのアップデートなど、すでに述べたこと以外では問題になるとは思えませんが、先週後半に行った唯一の他の変更は、CakeDayプラグインをインストールしたことです。

「いいね！」 1