Correos electrónicos de resumen no se envían para los usuarios a pesar de que se cumplen todas las condiciones (Discourse 3.6)

Soporte
,
1

Estamos en Discourse 3.6 y vemos un problema por el cual algunos usuarios que deberían recibir correos electrónicos de resumen nunca lo hacen.

Esto es lo que hemos confirmado para el usuario afectado:

  • enable_digest_emails es true

  • El usuario ha estado inactivo el tiempo suficiente para activar un resumen.

  • El correo electrónico es válido y está confirmado.

  • No hay rebotes ni supresiones por parte del proveedor de correo.

  • Otros correos electrónicos (notificaciones, etc.) se envían correctamente.

  • No aparece ningún correo electrónico de resumen en el registro de Administración → Correos electrónicos → Enviados.

  • Al usar Administración → Correos electrónicos → Prueba de resumen, el sistema muestra correctamente “Sí, se debería enviar un resumen”, pero en realidad no se envía ni se registra nada.

No aparecen errores relacionados en los registros de Sidekiq o de producción.

¿Alguien más ha visto que los correos electrónicos de resumen fallen silenciosamente en la versión 3.6, incluso cuando todas las configuraciones y comprobaciones de elegibilidad en la interfaz de administración indican que el usuario debería recibir uno?

2 Me gusta
2

¿Has revisado la configuración del usuario en la pestaña de correo electrónico de sus preferencias?

3

Sí, aquí está su configuración, y aquí está la representación de resumen para ellos diciéndonos que debe enviarse.

IMG_7947
IMG_79471290×2796 293 KB

IMG_7946
IMG_79461290×2796 243 KB

4

Actualización / Pasos de Reproducción (Discourse 3.6)

Ejecuté una reproducción explícita de esto usando la consola de Rails para confirmar lo que sucede a nivel de trabajo. Esto es lo que vemos para el usuario afectado:

sitio: hvac

ahora: 2025-10-15 17:23:01 UTC

disable_emails: “no”

disable_digest_emails: false

default_email_digest_frequency_minutes: 10080

ENV_DISABLE_EMAILS: nil

perform_deliveries: nil

smtp_address: “smtp.netcorecloud.net”

smtp_port: 587

– USUARIO –

id: 42122

username: milnerlarry

active: true

suspended: false

email_digests: true

digest_after_minutes: 10080

eligible_by_time: true

– ÚLTIMOS 15 REGISTROS DE CORREO ELECTRÓNICO –

2025-10-01 | type=digest | bounced=false

2025-09-22 | type=digest | bounced=false

perform_deliveries_now: true

Luego, cuando forcé la creación del resumen manualmente, Discourse cree que lo está creando pero devuelve:

mail = UserNotifications.digest(u)

=> Built digest mail: subject=nil bytes=50

Entonces, Discourse cree que está creando el resumen, pero en realidad está vacío (subject=nil), y por lo tanto se omite silenciosamente cuando se ejecuta el trabajo. No se crea ninguna entrada de EmailLog y no se envía nada.

Esto confirma:

  • El trabajo se pone en cola con éxito
  • SMTP y las entregas están habilitados
  • El trabajo de resumen finaliza sin errores porque el servicio de correo devuelve un resumen en blanco

Ejecutar el trabajo en línea con:

Jobs::UserEmail.new.execute(“type” => “digest”, “user_id” => u.id”)

produce el mismo resultado: no se crea ninguna fila nueva de EmailLog.

Causa Posible:

Parece que el resumen se omite debido a una condición de “resumen vacío”, ¿quizás algo cambió en la forma en que Discourse 3.6 evalúa el contenido para su inclusión? La vista Admin → Emails → Digest Test muestra el resumen correctamente, pero el trabajo en segundo plano no ve nada que incluir.

Resumen:

:white_check_mark: Usuario elegible

:white_check_mark: Correo electrónico activo + SMTP válido

:white_check_mark: La prueba de resumen de administrador se muestra correctamente

:prohibited: El trabajo de resumen en segundo plano se omite silenciosamente (resumen vacío)

:prohibited: No se registra EmailLog ni intento de envío

Me encantaría la confirmación del equipo: ¿hay posiblemente una regresión en cómo UserNotifications.digest recopila contenido en 3.6?

5

Realizando un poco más de trabajo aquí, encontramos un puñado (de 4k) de usuarios que en realidad reciben de manera confiable los resúmenes de actividad.

Comparar a uno de estos usuarios que recibe resúmenes con uno que no los recibe no muestra ninguna diferencia en su configuración.

===== xxxxx (ID: 4149) =====
Activo: true, Suspendido: false, Silenciado: false
Email confirmado: false
Digest habilitado: true
Frecuencia del digest: 10080 minutos
Última vez visto: 2025-03-24 20:58:55 UTC
Último email enviado: 2025-10-16 17:07:53 UTC
Categorías silenciadas:
Intento de digest de estadísticas de usuario: 2025-10-16 17:07:53 UTC
Total de emails enviados: 16
===== xxxxxxx (ID: 42206) =====
Activo: true, Suspendido: false, Silenciado: false
Email confirmado: false
Digest habilitado: true
Frecuencia del digest: 10080 minutos
Última vez visto: 2025-09-14 15:52:54 UTC
Último email enviado: 2025-10-01 23:30:33 UTC
Categorías silenciadas:
Intento de digest de estadísticas de usuario: 2025-10-16 17:32:34 UTC
Total de emails enviados: 2

Ciertamente hay otras configuraciones, pero pensé que esta era una comparación interesante de todos modos.

7

¿Alguien puede proporcionar un comando de Rails que podamos ejecutar para verificar cuántos resúmenes de actividad están realmente atrasados? Esencialmente, una verificación de estado de que el sistema está enviando los resúmenes según lo diseñado.

8

Puedes probar la siguiente consulta de consola de Rails, los usuarios activos que tienen activados los resúmenes por correo electrónico y que deben recibir su próximo correo electrónico de resumen

User.joins(:user_option)
  .where("user_options.email_digests = ?", true)
  .where("users.suspended_at IS NULL")
  .where("COALESCE(users.last_emailed_at, users.created_at) < (NOW() - INTERVAL '1 minute' * user_options.digest_after_minutes)")
  .count
9

¿Es posible que el resumen se omita porque el usuario no visitó por Suppress digest email after days?

10

@jahan_gagan eso es útil, pero eso nos dirá quién va a recibir un resumen de actividad/resumen, pero no quién NO recibió su resumen de actividad. ¿Tiene sentido? La pregunta es cómo vemos quién NO está recibiendo el resumen que debería.

11

@Moin lo tenemos configurado en 0; esto no debería ser un factor.

12

¿Estás seguro de que 0 deshabilita eso? ¿Has probado con un número grande en su lugar?

13

@Moin Gracias, lo cambié a 3000; no hay cambios en el resumen que se envía. Sigo viendo cientos con frecuencia semanal (ahora más de dos semanas) sin ser enviados.

14

De acuerdo, aquí hay una prueba para ver quién es elegible en este momento:

Screenshot 2025-10-23 at 1.19.51 PM
Screenshot 2025-10-23 at 1.19.51 PM947×298 70.5 KB

Vamos a forzar un envío ahora, y no se envía nada…

Screenshot 2025-10-23 at 1.21.37 PM
Screenshot 2025-10-23 at 1.21.37 PM872×347 67.5 KB

Tomando un usuario de muestra que no está recibiendo el resumen, y revisando la interfaz de administración, y parecen ser totalmente elegibles…

Screenshot 2025-10-23 at 1.24.25 PM
Screenshot 2025-10-23 at 1.24.25 PM923×703 44.6 KB

16

Así que, ante la falta de otras ideas, cambiamos la frecuencia de los resúmenes a diaria para todos los usuarios a través del administrador, a 1440.

Y de repente se enviaron todos los resúmenes…

¿Alguien tiene alguna idea de por qué es eso? Cambiar la frecuencia no debería tener ningún impacto dado que podemos ver que estos usuarios eran elegibles con la frecuencia semanal.

17

Hablando demasiado pronto, el cambio de frecuencia funcionó para un grupo de usuarios (un sitio) pero para otro no hizo nada. El misterio continúa…

18

Creo que puede deberse a uno de los últimos requisitos de la consulta que enlacé anteriormente.

Después de comprobar que el usuario es real, está activado, no está en preparación y no está suspendido, y comprobar que no ha deshabilitado los resúmenes y la frecuencia es mayor que 0, hay un correo electrónico principal y la puntuación de rebote es correcta, hay algunas comprobaciones basadas en el tiempo:

La última vez visto fue hace más de digest_after_minutes minutos.
La última vez visto está dentro de suppress_digest_email_after_days días.
La última comprobación de si el usuario debe recibir un resumen fue hace digest_after_minutes minutos.

Creo que la última puede ser la causa. Si Discourse intentó enviar el resumen ayer y digest_after_minutes es una semana, entonces no volverá a intentarlo hasta que haya pasado una semana. Si reduces eso, el próximo intento ocurre antes.

1 me gusta
19

@Jacob_Peebles ¡parece que has estado luchando con esto durante bastante tiempo! Creo que Digest Emails Not Sending to All Users – Need Help Debugging en marzo trata sobre el mismo problema, ¿verdad?

¿Te ayudó la última publicación de Moin? Si es así, háznoslo saber para que podamos cerrar este tema.