Migramos de uma Lista de E-mails e muitos usuários ainda usam nosso fórum predominantemente por e-mail.
Há cerca de 300 usuários no modo de Lista de E-mails. No entanto, o Discourse parece enviar apenas entre 75 e 80 e-mails quando um novo tópico é criado.
Comparei as configurações de usuário de Lista de E-mails de vários membros e elas são as mesmas.
Não há nada na seção de ignorados.
Não sei onde procurar para descobrir o que pode estar causando isso.
Todos os usuários estão ativados? Talvez eles não estejam recebendo nenhum e-mail?
Sim, todos estão ativados.
Infelizmente, também parece aleatório. Tenho algumas contas que uso para configurar coisas e elas também se comportam de maneira diferente.
Agora, verifiquei alguns tópicos mais antigos aqui e isso parece semelhante: https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
Pode ser o mesmo problema. No entanto, não sei como alterar as configurações conforme sugerido na solução daquele post.
Estou tentando executar o seguinte:
User.find_by_username(‘Neuer.test’).mailing_list_mode
mas recebo:
NoMethodError: método `mailing_list_mode’ não definido para #User:0x00005569c4038af8
O modo de lista de e-mails está configurado na tabela user_options. Tente executar UserOption.where(mailing_list_mode: true). Para obter os IDs de todos os usuários com o modo de lista de e-mails ativado, execute UserOption.where(mailing_list_mode: true).pluck(:user_id)
Obrigado, @simon.
Gerei uma lista conforme sugerido em sua postagem. Na verdade, são várias listas. Ela gera uma lista de IDs de usuários e, ao chegar a cerca de 50, exibe :...skipping... e depois recomeça com os mesmos IDs de usuários, adicionando um novo no final e repetindo esse processo cerca de 4 ou 5 vezes. No meio, há uma seção inteira apenas com linhas em branco. Mas isso pode ser um comportamento normal?
De qualquer forma, isso está longe de ser uma lista completa de usuários inscritos no modo de lista de e-mail (apenas 58, enquanto eu esperava cerca de 350).
Em seguida, executei algumas verificações nos IDs e nenhum deles recebeu a última postagem, por exemplo.
Também executei UserOption.where(mailing_list_mode: false).pluck(:user_id), que retornou outras 29 entradas.
Executar UserOption.where(mailing_list_mode: 1).pluck(:user_id) retornou um número semelhante ao de true e os mesmos usuários.
No total, encontrei apenas cerca de 90 dos 400 usuários ativados. Tudo muito estranho e não entendo o que está acontecendo.
Qualquer ajuda será muito apreciada.
P.S. Como sair após o último : no final dos resultados da pesquisa, para que eu possa executar outra consulta?
Quando a consulta retorna mais texto do que cabe na tela, ela o exibe com menos. Você pode pesquisar no Google como funciona.
Espaço vai para a próxima tela, / para pesquisar, q para sair.
Então, acho que parece que você está recebendo e-mails entregues aos usuários ativos. Os outros podem estar inativos?
Obrigado, Jay.
Não, temos mais de 450 usuários ativos. Não consigo identificar um padrão. Analisei uma postagem anterior de alguns dias atrás, que foi enviada para 334 usuários no modo de lista de e-mails.
A única mudança desde então foi que adicionamos um registro SPF ao nosso DNS, pois estávamos com dificuldades para enviar e-mails para o Google. No entanto, isso foi feito no nosso servidor de e-mail; não alterei nenhuma configuração SMTP no Discourse.
@pfaffman Acabei de instalar o Data Explorer. Talvez eu possa executar uma consulta lá em vez disso?
Isso está começando a me deixar maluco 
Eu ia postar que, de alguma forma, tudo parecia ter se resolvido sozinho, já que 336 pessoas receberam várias postagens recentes.
Mas então vieram duas respostas a uma postagem em rápida sucessão, ambas do mesmo usuário. 181 membros receberam ambas as mensagens, 38 receberam apenas uma mensagem, deixando 117 sem nenhum e-mail.
Existe algum outro log em algum lugar que eu possa consultar para entender melhor isso? Não há nada no Sidekiq.
O problema parece ser um erro 421.4.7.0: muitas conexões a partir do endereço IP.
Estranhamente, isso parece ocorrer principalmente com um único membro.
Como posso corrigir isso?
Aqui está o que os registros indicam:
Mensagem (1957 cópias reportadas)
Exceção de trabalho: 421 4.7.0 dd27022.xxxxxx.com Erro: muitas conexões a partir de xxx.xxx.xx.xxx
### Rastreamento
/usr/local/lib/ruby/2.6.0/net/smtp.rb:969:in `check_response'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.1/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.1/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:114:in `block in deliver_now'
actionmailer-6.0.1/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:113:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:212:in `send'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:90:in `block (2 levels) in execute'
/var/www/discourse/app/models/email_log.rb:35:in `block in unique_email_per_post'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/email_log.rb:31:in `unique_email_per_post'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:89:in `block in execute'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block (2 levels) in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:238:in `block in in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `loop'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:135:in `find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:69:in `find_each'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:61:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.4/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.4/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.4/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.4/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.4/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.4/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.4/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.4/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.4/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.4/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.4/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.4/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.4/lib/sidekiq/util.rb:24:in `block in safe_thread'
Você precisará entrar em contato com seu provedor de e-mail, pois isso não tem nada a ver com o Discourse.
@codinghorror
Então, mudei o provedor de e-mail e agora estou enviando via Amazon SES. Isso parece ter resolvido o problema por algumas semanas. Agora o Discourse começou a parar aleatoriamente o envio de e-mails no meio da entrega para os assinantes da lista de e-mails novamente. Não há erros nos logs. Recriei o container e, por enquanto, parece estar tudo bem novamente. Há algum outro lugar onde posso procurar um log de erro potencial?
Há tarefas presas no Sidekiq?
Não, infelizmente não há.
Estou enfrentando um problema semelhante nos últimos dias. Os e-mails não estão sendo enviados para os usuários da lista de distribuição, não há tarefas retidas no Sidekiq e estou recebendo o mesmo erro nos logs. Já tentei reconstruir, mas parece não fazer diferença. Isso está causando muita angústia para nossos usuários.
Parece que, após uma reconstrução, se uma nova postagem for recebida, ela é enviada, mas após isso, nenhuma postagem ou resposta subsequente é enviada.
Qualquer ajuda seria muito apreciada!
Ed
Isso está se tornando um problema realmente frustrante para mim.
Hoje, o Discourse decidiu parar de enviar e-mails para os assinantes da lista de distribuição após entregar apenas 15 mensagens. Não se trata de um problema do provedor, pois já mudei de provedor. Também não há mensagens de erro no log ou nada travado no Sidekiq.
Parece que a única solução possível é fazer uma reconstrução.
Existe alguma maneira de agendar automaticamente uma reconstrução em intervalos de tempo definidos? Pelo menos assim, não precisarei monitorá-la constantemente.
Você pode configurar uma tarefa cron para fazer isso.
Alguns usuários não atingiram o limite máximo de e-mails por dia? Eles não desativaram os e-mails? (isso não explicaria por que uma reconstrução resolveria algo). Você tem memória RAM suficiente? Não há nada nos logs?
out of memory é uma mensagem de erro bastante clara.
EDIT: Ops. Eu te confundi com outro tópico, então essas informações sobre multisite, embora todas verdadeiras, podem não fazer sentido aqui.
Tenho quase certeza de que minha instância exclusiva para multisite está rodando com 4 GB de RAM, mas ela também não tem mysql, apache e wordpress rodando. Meu site com (staging + production)*(discourse + wordpress) me deu muito trabalho antes de eu aumentá-lo para 8 GB. Isso inclui containers para postgres, redis, traefik, prometheus e mariadb, além de 2 cada para WP e Discourse (não multisite, já que o staging precisa poder ter plugins diferentes do production).
Se economizar dinheiro é o seu objetivo e você tem sites Discourse de baixo volume, provavelmente o melhor caminho é colocar cada um em um droplet separado de $5 (1 GB).
Sim, eu percebi 
Estou em uma CPU compartilhada padrão e executando apenas um site Discourse no meu droplet.