Hemos migrado desde una lista de correo y muchos usuarios siguen utilizando nuestro foro principalmente a través del correo electrónico.
Hay alrededor de 300 usuarios en modo de lista de correo, pero Discourse solo parece enviar entre 75 y 80 correos cuando se agrega un nuevo tema.
He comparado la configuración de usuario de lista de correo de varios miembros y son iguales.
No hay nada en la sección de omitidos.
No sé dónde buscar lo que podría estar causando esto.
1 me gusta
¿Están todos los usuarios activados? ¿Quizás no están recibiendo ningún correo?
Sí, todos están activados.
Por desgracia, también parece aleatorio; tengo varias cuentas que utilizo para configurar cosas y se comportan de manera diferente.
Ahora he revisado algunos temas antiguos aquí y esto parece similar: https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
Podría ser el mismo problema. Sin embargo, no sé cómo cambiar la configuración como se sugiere en la solución de ese post.
Estoy intentando ejecutar esto:
User.find_by_username(‘Neuer.test’).mailing_list_mode
pero obtengo:
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
El modo de lista de correo está configurado en la tabla user_options. Intenta ejecutar UserOption.where(mailing_list_mode: true). Para obtener los IDs de usuario de todos los usuarios con el modo de lista de correo habilitado, ejecuta UserOption.where(mailing_list_mode: true).pluck(:user_id)
5 Me gusta
Gracias @simon
He generado una lista como se sugirió en tu publicación. En realidad, son varias listas. Genera una lista de IDs de usuario y llega a unos 50, luego dice :...skipping... y vuelve a comenzar con los mismos IDs de usuario, añadiendo uno nuevo al final y repitiendo esto unas 4 o 5 veces.. Entre medio hay toda una sección de líneas en blanco. Pero eso podría ser un comportamiento normal.
En cualquier caso, esto está muy lejos de ser una lista completa de usuarios suscritos mediante el modo de lista de correo (solo 58, y esperaba alrededor de 350).
Luego ejecuté algunas verificaciones en los IDs y ninguno de ellos recibió la última publicación, por ejemplo.
También ejecuté UserOption.where(mailing_list_mode: false).pluck(:user_id), lo que arrojó otras 29 entradas.
Ejecutar UserOption.where(mailing_list_mode: 1).pluck(:user_id) dio un número similar al de true y los mismos usuarios.
En total, solo encontré alrededor de 90 de los 400 usuarios activados. Todo muy extraño y no entiendo qué está pasando.
Cualquier ayuda será muy apreciada.
P.D. ¿Cómo salgo después del último : al final de los resultados de la búsqueda, para poder ejecutar otra consulta?
1 me gusta
Cuando la consulta devuelve más texto del que cabe en la pantalla, lo muestra de forma resumida. Puedes buscar en Google cómo funciona.
La tecla Espacio pasa a la siguiente pantalla, / busca y q sale.
Así que creo que suena a que estás recibiendo correos enviados a los usuarios activos. ¿Los demás podrían estar inactivos?
1 me gusta
Gracias, Jay.
No, tenemos más de 450 usuarios activos. No puedo ver realmente un patrón; revisé una publicación anterior de hace unos días y esa se envió a 334 usuarios mediante el modo de lista de correo.
Lo único que ha cambiado desde entonces es que añadimos un registro SPF a nuestro DNS, ya que teníamos problemas para enviar correos a Google. Pero eso fue en nuestro servidor de correo; no modifiqué ninguna configuración SMTP en Discourse.
@pfaffman Acabo de instalar Data Explorer, ¿quizás haya una consulta que pueda ejecutar allí en su lugar?
Esto me está volviendo loco 
Iba a publicar que, de alguna manera, todo parecía haberse “resuelto solo”, ya que 336 personas recibieron varios mensajes recientes.
Luego llegaron dos respuestas a un mensaje en rápida sucesión, ambas del mismo usuario. 181 miembros recibieron ambos mensajes, 38 recibieron uno, dejando a 117 sin ningún correo electrónico.
¿Hay algún otro registro en algún lugar que pueda consultar y que pueda arrojar luz sobre esto? No hay nada en Sidekiq.
El problema parece ser un error 421.4.7.0: demasiadas conexiones desde la dirección IP.
Curiosamente, parece ocurrir principalmente con un solo miembro.
¿Cómo puedo solucionarlo?
Esto es lo que indican los registros:
Mensaje (1957 copias reportadas)
Excepción del trabajo: 421 4.7.0 dd27022.xxxxxx.com Error: demasiadas conexiones desde xxx.xxx.xx.xxx
### Rastreo de la pila
/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'
Tendrás que consultar con tu proveedor de correo electrónico, no tiene nada que ver con Discourse.
1 me gusta
@codinghorror
Así que cambié de proveedor de correo y ahora estoy enviando a través de Amazon SES. Esto pareció solucionarlo durante unas semanas. Ahora Discourse ha comenzado a detener aleatoriamente el envío de correos a mitad de la entrega a los suscriptores de la lista de correo nuevamente. No hay errores en los registros. He reconstruido el contenedor y, por ahora, parece estar bien de nuevo. ¿Hay algún otro lugar donde pueda buscar un registro de error potencial?
¿Hay tareas retenidas en Sidekiq?
No, por desgracia no.
1 me gusta
He tenido un problema similar en los últimos días. Los correos electrónicos no se envían a los usuarios de la lista de distribución, no hay trabajos retenidos en Sidekiq y aparece el mismo error en el registro. He intentado reconstruir el sistema, pero parece que no marca ninguna diferencia. Esto está causando mucha angustia a nuestros usuarios.
Lo que parece ocurrir es que, tras una reconstrucción, si se recibe una nueva publicación, esta se envía, pero después de eso no se envían publicaciones o respuestas posteriores.
¡Cualquier ayuda sería muy apreciada!
Ed
Esto se está convirtiendo en un problema realmente frustrante para mí.
Hoy, Discourse decidió dejar de enviar correos a los suscriptores de la lista de correo después de entregar solo 15 mensajes. No es un problema del proveedor, ya que ya he cambiado de proveedor. Tampoco hay mensajes de error en los registros ni nada detenido en Sidekiq.
Parece que la única solución posible es una reconstrucción.
¿Existe alguna forma de programar automáticamente una reconstrucción en intervalos de tiempo específicos? Al menos así no tendría que monitorearlo constantemente.
Podrías configurar un trabajo cron para hacer eso.
¿No has alcanzado el límite de correos electrónicos diarios para algunos usuarios? ¿No han desactivado los correos electrónicos? (eso no explicaría por qué una reconstrucción solucionaría algo). ¿Tienes suficiente RAM? ¿Nada en los registros?
1 me gusta
out of memory es un mensaje de error bastante claro.
EDIT: Uf. Te confundí con otro tema, así que esto sobre multisitio, aunque todo es cierto, puede que no tenga sentido aquí.
Estoy bastante seguro de que mi instancia exclusiva para multisitio se ejecuta con 4 GB de RAM, pero tampoco tiene MySQL, Apache y WordPress ejecutándose. Mi sitio con (staging + production)*(discourse + wordpress) me dio muchos problemas antes de aumentarlo a 8 GB. Eso incluye contenedores para Postgres, Redis, Traefik, Prometheus y MariaDB, más 2 para WordPress y 2 para Discourse (no multisitio, ya que el entorno de staging necesita poder tener plugins diferentes a los de producción).
Si ahorrar dinero es tu prioridad y tienes sitios de Discourse de bajo volumen, probablemente lo mejor sea tener cada uno en un droplet separado de 5 $ (1 GB).
1 me gusta
Sí, ya lo pensé 
Estoy en una CPU compartida estándar y solo ejecuto un sitio de Discourse en mi droplet.