Mein aktuelles Verständnis ist, dass Email::Processor.process!Email::Receiver.new mit mail=nil aufruft, was eine Email::Receiver.EmptyEmailError auslöst und @receiver undefiniert lässt.
Der folgende rescue-Teil erwartet einen initialisierten @receiver.
Sollte Email::Processor.initialize nicht einen Fehler auslösen, wenn es mit mail==nil aufgerufen wird?
Update: Ok, definitiv bestätigt, dass dies das Problem ist. Dank der Analyse von @thoka weiß ich jetzt, wonach ich suchen muss, das Problem sind tatsächlich leere E-Mails. Beachten Sie, wie die Nachrichten bis zu dem Punkt ungelesen sind, an dem eine leere E-Mail erscheint?
Leere E-Mails blockieren das System derzeit, zumindest ab einer bestimmten Anzahl, da es anscheinend ein Glücksspiel ist, ob es dauerhaft blockiert wird oder nicht.
Wir müssen die Dinge vorerst beobachten, aber es wäre großartig, wenn dies behoben werden könnte. Danke!!
Hallo @mekentosj, ich untersuche dieses Problem. Weißt du, wie die leeren E-Mails derzeit generiert werden? Ich frage mich, ob es eine Ursache gibt, die ich untersuchen muss (neben der Behebung des Fehlers).
Großartig, vielen Dank, dass Sie sich darum kümmern! Ich bin mir nicht ganz sicher, wie sie diese E-Mails versenden. Die Beispiele im Screenshot scheinen Antworten zu sein, bei denen jemand (oder seine E-Mail-App) einfach den gesamten Inhalt des Textkörpers entfernt hat, bevor er geantwortet hat (es scheint häufiger bei Leuten vorzukommen, die auf Chinesisch antworten, also vielleicht ein Problem mit der Zeichenkodierung oder eine bestimmte Art von E-Mail-App). Aber andere Wege, die ich mir vorstellen könnte, die in unserem Setup relevant/möglich wären, sind, dass jemand uns nur eine E-Mail mit einem Anhang ohne Textkörper und nur einem Betreff sendet, oder (manche Leute tun das anscheinend immer noch) ihre Frage vollständig im E-Mail-Betreff, ohne Textkörper.
Tatsächlich habe ich gerade die E-Mail gefunden, ich werde die EML-Datei in einer DM senden (da sie die E-Mail-Adresse des Benutzers enthält), vielleicht enthält sie weitere Hinweise.
Danke, die E-Mail scheint von einem Drittanbieter (Tencent/China) generiert worden zu sein. Ich habe mir die E-Mail-Header angesehen und einige ungewöhnliche Dinge bemerkt (ich habe die interessanten Teile unten hervorgehoben). Die E-Mail enthält überhaupt keinen Text, aber sie scheint eine automatische Antwort auf eine E-Mail zu sein, die an dieses QQ-Postfach gesendet wurde.
Ich habe kurz nach X-QQ-MIME gesucht und es scheint, dass eine Reihe anderer Websites ähnliche Probleme bei der Verarbeitung von E-Mails von Adressen mit der Domain qq.com haben.
Ich denke, es ist sicher für uns, alle E-Mails zu überspringen, die keinen E-Mail-Text enthalten. Wir können sie stillschweigend protokollieren und verhindern, dass der Fehler ausgelöst wird.
Cool, das bestätigt also mein Gefühl, dass es hauptsächlich chinesische Nutzer unserer Community betraf.
Ich denke, es ist sicher für uns, alle E-Mails zu überspringen, die keinen E-Mail-Body enthalten. Wir können sie stillschweigend protokollieren und verhindern, dass der Fehler auftritt.
Ja, solange keine E-Mails übersprungen werden, die nur Anhänge enthalten, auch wenn der Absender nichts getippt hat (ich bin kein E-Mail-Experte, vielleicht enthält das trotzdem einen Body).
Das andere von mir erwähnte Szenario, bei dem der Benutzer nur den Betreff eingibt, aber die E-Mail leer lässt, wird wahrscheinlich bereits übersprungen? Wenn nicht, müssten Sie diese irgendwie von den problematischen E-Mails identifizieren.
Die Alternative wäre, dass das Header-Feld X-QQ-AUTO-REPLY: true erkannt wird, bevor der Fehler durch den Mechanismus ausgelöst wird, der automatisch generierte E-Mails erkennt.
Zusätzlich möchten Sie diesen speziellen Fehler wahrscheinlich immer noch beheben, indem Sie tun, was Sam vorgeschlagen hat.
Ich habe die E-Mail-Betreffzeile base64-dekodiert und erhalten: 你好，我是Focus and Flat Agile 17
Ich denke, das liegt an den chinesischen Zeichen, die vor dem Senden base64-kodiert werden. Das erklärt das verstümmelte Format für den Absendernamen und den Betreff.
Ich hoffe, die vorhandene Logik berücksichtigt dies bereits, aber ich werde prüfen, wie wir Anhänge und E-Mail-Betreffzeilen bei der Verarbeitung von E-Mails von POP3 handhaben.
Ich denke, dies würde von der aktuellen E-Mail-Verarbeitungslogik übersprungen werden. Wenn kein Text im Body vorhanden ist, aber alles andere vorhanden ist, erhalte ich:
Email can not be processed: Email::Receiver::NoBodyDetectedError
Ich habe dies getestet, indem ich einen leeren Gmail Multipart Body für Plaintext und HTML verwendet habe:
Ich habe ein Update vorgenommen, um den durch is_bounce? verursachten Fehler zu verhindern.
Es gibt eine Website-Einstellung für die Protokollierung von E-Mail-Verarbeitungsprotokollen:
SiteSetting.log_mail_processing_failures
Protokolliert alle Fehler bei der E-Mail-Verarbeitung nach /logs
Wenn diese aktiviert ist, wird der Fehler bei leeren E-Mails weiterhin in den E-Mail-Protokollen angezeigt, aber der Job wird nicht wie derzeit fehlschlagen. Ich habe die Commit-Details hier als Referenz hinzugefügt:
Ich sehe diesen Fehler in den Protokollen, hat das damit etwas zu tun? Es scheint, dass wir seit Tagen keine E-Mails von unserem POP3 erhalten haben und dies viele Probleme verursacht. Ich habe überprüft und habe keine leeren E-Mails auf POP3, wie kann ich es wieder zum Laufen bringen? Ich habe gerade auf die neueste Version aktualisiert, das hat nicht geholfen.
750194 E-Mail kann nicht verarbeitet werden: Email::Receiver::EmptyEmailError
/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:23:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:43:in `block (2 levels) in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:669:in `each'
net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:40:in `block in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:39:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:249:in `block (2 levels) in perform'
rails_multisite-4.0.1/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:236:in `block in perform'
/var/www/discourse/app/jobs/base.rb:232:in `each'
/var/www/discourse/app/jobs/base.rb:232:in `perform'
/var/www/discourse/app/jobs/base.rb:297:in `perform'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:122:in `process_queue'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:70:in `worker_loop'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:59:in `block (2 levels) in ensure_worker_threads'
irgendwie explodiert.
