Meu entendimento atual é que Email::Processor.process! chama Email::Receiver.new com mail=nil, o que levanta um Email::Receiver.EmptyEmailError, deixando @receiver indefinido.
A parte rescue seguinte espera um @receiver inicializado.
O Email::Processor.initialize não deveria levantar algum erro quando chamado com mail==nil?
Atualização: Ok, definitivamente confirmado que este é o problema. Graças à análise de @thoka, agora sei o que procurar, o problema são de fato e-mails vazios. Note como as mensagens ficam não lidas exatamente até o ponto em que um e-mail vazio aparece?
Portanto, e-mails em branco atualmente travam o sistema para nós, pelo menos além de um certo número, porque parece ser um pouco aleatório se ele fica permanentemente travado ou não.
Acho que teremos que monitorar as coisas por enquanto, mas seria ótimo se isso pudesse ser corrigido. Obrigado!!
Olá @mekentosj, estou investigando este problema. Você sabe como os e-mails em branco estão sendo gerados atualmente? Estou imaginando se há uma causa raiz que preciso investigar (junto com a correção do erro).
Ótimo, obrigado por investigar isso! Não tenho certeza de como eles conseguem enviar esses e-mails. Os exemplos na captura de tela parecem ser respostas em que alguém (ou seu aplicativo de e-mail) simplesmente removeu todo o conteúdo do corpo antes de responder (parece ocorrer com mais frequência com pessoas respondendo em chinês, então talvez um problema de codificação de caracteres ou um certo tipo de aplicativo de e-mail). Mas outras maneiras que eu poderia imaginar que seriam relevantes/possíveis em nossa configuração é alguém nos enviar um e-mail apenas com um anexo sem conteúdo no corpo e apenas um assunto, ou (algumas pessoas ainda parecem fazer isso), sua pergunta inteiramente no assunto do e-mail, sem conteúdo no corpo.
Na verdade, acabei de encontrar o e-mail, enviarei o arquivo eml em uma DM (pois contém o endereço de e-mail do usuário), talvez ele contenha mais pistas.
Obrigado, o e-mail parece ter sido gerado por um terceiro (Tencent/China). Dei uma olhada nos cabeçalhos do e-mail e notei algumas coisas incomuns (destaquei as partes interessantes abaixo). O e-mail não contém corpo algum, mas parece ser uma resposta automática a um e-mail enviado para essa caixa de correio qq.
Fiz uma rápida pesquisa por X-QQ-MIME e parece que vários outros sites estão enfrentando problemas semelhantes ao processar e-mails de endereços qq.com.
Acho que é seguro ignorarmos qualquer e-mail que não contenha o corpo do e-mail. Podemos registrá-lo silenciosamente e impedir que o erro seja gerado.
Legal, então sim, isso confirma minha sensação de que estava afetando principalmente usuários chineses de nossa comunidade.
Acho que é seguro pularmos qualquer e-mail que não contenha o corpo do e-mail. Podemos registrá-lo silenciosamente e impedir que o erro seja gerado.
Sim, desde que não pule e-mails que contenham apenas anexos, mesmo que o remetente não tenha digitado nada (não sou especialista em e-mail, então talvez isso ainda contenha um corpo).
O outro cenário que mencionei, onde o usuário digitaria apenas no assunto, mas deixaria o e-mail em branco, acho que já é pulado atualmente? Se não for, você teria que identificar esses e-mails problemáticos de alguma forma.
A alternativa seria ter o campo de cabeçalho X-QQ-AUTO-REPLY: true reconhecido antes que o erro seja gerado pelo mecanismo que detecta e-mails gerados automaticamente.
Além disso, você provavelmente ainda vai querer que esse erro específico seja resolvido fazendo o que Sam sugeriu
Eu decodifiquei o assunto do e-mail em base64 e obtive: 你好，我是Focus and Flat Agile 17
Acho que isso se deve aos caracteres chineses, que são codificados em base64 antes do envio. Isso explica o formato ilegível para o nome do remetente e o assunto.
Espero que a lógica existente já lide com isso, mas vou verificar como lidamos com anexos e assuntos de e-mail ao processar e-mails do pop3.
Acho que isso seria pulado pela lógica de processamento de e-mail atual. Quando não há texto no corpo, mas tudo o mais está no lugar, eu recebo:
Email can not be processed: Email::Receiver::NoBodyDetectedError
Eu testei isso usando um corpo vazio do Gmail multipart para texto simples e html:
Fiz uma atualização para evitar o erro causado por is_bounce?.
Existe uma configuração do site para rastrear logs de e-mail:
SiteSetting.log_mail_processing_failures
Registra todas as falhas de processamento de e-mail em /logs
Se isso estiver ativado, o erro de e-mail em branco ainda aparecerá nos logs de e-mail, mas não fará com que o trabalho falhe como acontece atualmente. Adicionei os detalhes do commit aqui para referência:
Estou vendo este erro nos logs, isso está relacionado? Parece que não recebemos e-mails do nosso POP3 há dias e isso está causando muitos problemas. Verifiquei e não tenho e-mails vazios no POP3, como posso resolver isso? Acabei de atualizar para a versão mais recente e isso não ajudou.
750194 Email não pode ser processado: 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'
está explodindo.
