Seit meinem letzten Discourse-Update vor ein paar Tagen scheint die Antwort-E-Mail nicht mehr zu funktionieren, sie wird nicht empfangen und aktualisiert somit das Thema nicht. Auch die gesendeten E-Mails für beobachtete Kategorien verhalten sich nicht richtig, es werden nur 5 von 65 gesendet.
Hatte sonst noch jemand in letzter Zeit E-Mail-Probleme?
Ja, ich habe leider die gleichen Probleme mit 3.4.0.beta4-dev. Ich habe alles versucht, von der Neubewertung der app.yml-Datei bis zur Überprüfung der Mail-DNS-Einstellungen. Ironischerweise konnte ich vom Terminal aus über SMTP im Discourse-Docker-Container mit wasm senden. Was meiner Meinung nach von einem Konfigurationsfehler irgendwo herrühren könnte. Dies ist ein großes Problem für alle registrierten Benutzer, die keine E-Mails für Beiträge, Newsletter und Passwort-Resets erhalten können. Die 550 ERR-Nachricht besteht seit dem neuen Update. Jetzt bete ich, dass ein Rollback auf v3.4.0.beta2 diesen Fehler beheben würde.
Gut, dass es nicht nur mir so geht, hoffentlich beheben einige Entwickler dieses Problem so schnell wie möglich. Ich habe keine Ahnung, wie ich ein Rollback durchführen kann.
Installiert
3.4.0.beta4-dev
58f75ed205
Gleichzeitig fand auch ein Postgres-Datenbank-Update von 13 auf 15 statt.
Ich weiß nicht, ob das Postgres-Update die Einstellungen in der GUI durcheinander gebracht hat, da mir aufgefallen ist, dass das Hinzufügen von POP3-Serverinformationen für das Polling keine Änderungen an der Datei app.yml von Discourse bewirkt hat … sehr seltsam. Das Zurückrollen ist etwas knifflig, da man in die Git-Tags einsteigen und die gesamte Anwendung aus Versionen neu erstellen muss. Die Verwendung von ChatGPT kann bei der Fehlerbehebung helfen.
Hat es funktioniert, indem Sie eine Version zurückgerollt haben?
Ich hoffe, dass das Entwicklerteam dies sehr bald in Angriff nimmt und eine Vorwärtskorrektur erstellt.
Ich habe mehrmals versucht, git checkout v3.4.0.beta2 im Docker auszuführen, um zurückzurollen, obwohl ich auch die Datei app.yml angegeben habe. Ich werde also sehen, ob es eine Kontaktperson bei Discourse gibt, um diesen 550-Fehler-Bug für beta5 bald zu beheben.
Wo sehen Sie diesen Fehler? Ich habe nur große Probleme mit E-Mails, bin mir aber nicht sicher, wo ich den 550-Fehler sehen kann, danke
Ich sehe keine Fehler in den E-Mail-Protokollen über die GUI, nur die Antworten werden nicht empfangen und die gesendeten E-Mails gehen nur an wenige Personen, obwohl sie an etwa 65 Personen gehen sollten.
Ich sehe das in /logs:
Bitte erwähnen Sie keine Teammitglieder mit @.
Wenn Sie ein zahlender Discourse-Kunde sind, erhalten Sie Prioritätsunterstützung, indem Sie sich an team@discourse.org wenden, andernfalls ist dies nach bestem Wissen und Gewissen.
Geben Sie bei der Meldung bitte an, welchen E-Mail-Anbieter Sie verwenden. Möglicherweise gab es bei einem häufig verwendeten E-Mail-Anbieter für Discourse Rückschritte. Ich weiß es nicht.
Es tut mir so leid, das habe ich nicht bemerkt, das werde ich nicht wieder tun. Vielen Dank, dass Sie mich darauf hingewiesen haben.
Ich benutze Brevo, aber ich glaube nicht, dass es mit Brevo zusammenhängt, basierend auf dem, was ich sehe, dass einige E-Mails rausgehen.
Die Antworten kommen über Gmail, aber das hat immer funktioniert.
Vielleicht kann der andere Antwortende uns wissen lassen, was er benutzt. Er hat das gleiche Problem.
Es befindet sich unter Serverprotokolle und Berichte. Kann Test-E-Mail senden und gibt im Tab „Übersprungen“ einen 550-Mail-Fehler zurück. Habe nichts von Entwicklern gehört. Ich denke, auch mit dem PostGres 15-Update wurden die Einstellungen möglicherweise nicht an die Datenbank übertragen, um ausgeführt zu werden, wenn app.yml eine Kommunikation erfordert.
Ich kann erfolgreich eine Test-E-Mail senden, ohne Fehler. Diese Test-E-Mail wird über Brevo versendet.
Das Problem für mich ist, dass die E-Mails der beobachteten Kategorie nur an wenige Benutzer gesendet werden. Die fehlenden E-Mails werden nicht als übersprungen angezeigt. Die Mehrheit der Benutzer erhält die E-Mails einfach nicht.
Das zweite Problem ist, dass die Antwort-E-Mails nie im System ankommen.
Diese Probleme traten erst nach dem letzten Upgrade auf.
Ich verwende Ubuntu 22.04, das kürzlich ebenfalls ein Container-Upgrade erhalten hat, aber das E-Mail-Problem ist mir erst aufgefallen, nachdem ich Discourse aktualisiert hatte, was natürlich auch Postgres aktualisiert hat.
Welches Betriebssystem verwendest du, Phil?
Dies taucht im Produktionsprotokoll häufig auf:
E-Mail kann nicht verarbeitet werden: Email::Receiver::EmptyEmailError
tail -1000 production.log-20250202 | grep ‘Email::Receiver::EmptyEmailError’ | wc -l
291
Ich sehe dieses Thema, verstehe aber die Lösung nicht. Kann mir das jemand bitte erklären? Wo befindet sich der Posteingang? Ich kann meinen Posteingang sehen, wenn ich für mein Konto zweimal auf Nachrichten klicke, und diese Nachrichten löschen, aber es sind nicht viele. Wie sehe ich also alle eingehenden Antwort-E-Mails, welchen Posteingang usw.?
Sehen Sie mehr Details, wenn Sie auf den Fehler klicken? Es könnte sehr gut sein, dass eine einzelne E-Mail seltsam/schlecht formatiert ist, und wir planen den Job, der sie verarbeiten soll, immer wieder neu.
Hinweis: Ich habe gerade einen Beitrag zu einem Thema gepostet, der 65 E-Mails hätte erstellen sollen, aber nur 5 im Postausgang erstellt hat, ohne dass etwas übersprungen wurde usw. Keine Fehlermeldung und keine Warnung.
Es gibt einen Fehler in /logs von gestern und eine Warnung, ich habe keine Ahnung, ob sie mit meinen E-Mail-Problemen zusammenhängen:
Nachricht (552 Kopien gemeldet)
Job-Ausnahme: 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/3.3.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'
Nachricht (694 Kopien gemeldet)
E-Mail kann nicht verarbeitet werden: 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/3.3.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'
Woher wissen Sie, dass 65 E-Mails hätten erstellt werden sollen?
Ich weiß genau, wer “Watched categories” eingerichtet hat, und dies ist eine “Watched category”, und keine Benutzer haben Benachrichtigungen stummgeschaltet. Es sollten absolut 65 E-Mails versendet werden, wie es vor dem Update immer der Fall war.
Ich werde heute später auf die neue Version aktualisieren und sehen, ob das einen Unterschied macht, von 3.4.0.beta4-dev auf die neue Version.
Ich werde auch die VM neu starten. Ich gehe davon aus, dass dies die Datenbank ordnungsgemäß neu startet, die übrigens korrekt gemäß der Dokumentation installiert wurde, als ich auf 3.4.0.beta4-dev aktualisiert habe.
Abgesehen von dem, was ich bereits erwähnt habe, wie die Ubuntu22.04 O/S-Updates für containerd, würde ich nicht denken, dass es ein Problem wäre, aber die einzige andere Änderung, die ich letzte Woche vorgenommen habe, war die Installation des CakeDay-Plugins.