Emails récapitulatifs non envoyés pour les utilisateurs malgré la réunion de toutes les conditions (Discourse 3.6)

Soutien
,
1

Nous utilisons Discourse 3.6 et rencontrons un problème où certains utilisateurs qui devraient recevoir des e-mails de résumé ne les reçoivent jamais.

Voici ce que nous avons confirmé pour l’utilisateur concerné :

  • enable_digest_emails est vrai

  • L’utilisateur est inactif depuis suffisamment longtemps pour déclencher un résumé

  • L’e-mail est valide et confirmé

  • Aucun rebond ou suppression de la part du fournisseur de messagerie

  • Les autres e-mails (notifications, etc.) sont envoyés correctement

  • Aucun e-mail de résumé n’apparaît dans le journal Admin → Emails → Sent

  • Lors de l’utilisation de Admin → Emails → Digest Test, le système indique correctement « Oui, un résumé devrait être envoyé » — mais rien n’est réellement envoyé ni consigné.

Aucune erreur connexe n’apparaît dans les journaux Sidekiq ou de production.

Quelqu’un d’autre a-t-il constaté des échecs silencieux des e-mails de résumé sur la version 3.6, même lorsque tous les paramètres et vérifications d’éligibilité dans l’interface d’administration indiquent que l’utilisateur devrait en recevoir un ?

2 « J'aime »
2

Avez-vous vérifié les paramètres de l’utilisateur dans l’onglet e-mail de ses préférences ?

3

Oui, voici leurs paramètres, et voici le rendu du résumé pour eux nous indiquant qu’il doit être envoyé.

IMG_7947
IMG_79471290×2796 293 KB

IMG_7946
IMG_79461290×2796 243 KB

4

Mise à jour / Étapes de reproduction (Discourse 3.6)

J’ai effectué une reproduction explicite de ce problème en utilisant la console Rails pour confirmer ce qui se passe au niveau des tâches. Voici ce que nous observons pour l’utilisateur concerné :

site : hvac

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

disable_emails : “non”

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

– UTILISATEUR –

id : 42122

username : milnerlarry

active : true

suspended : false

email_digests : true

digest_after_minutes : 10080

eligible_by_time : true

– DERNIERS 15 JOURNAUX D’EMAIL –

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

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

perform_deliveries_now : true

Ensuite, lorsque j’ai forcé la construction manuelle du digest, Discourse pense qu’il le construit mais renvoie :

mail = UserNotifications.digest(u)

=> Digest mail construit : subject=nil bytes=50

Donc, Discourse pense qu’il construit le digest, mais il est en fait vide (subject=nil) – et est donc silencieusement ignoré lorsque la tâche s’exécute. Aucune entrée EmailLog n’est créée et rien n’est envoyé.

Ceci confirme :

  • La tâche s’enfile avec succès
  • Le SMTP et les envois sont activés
  • La tâche de digest se termine sans erreur car le service de messagerie renvoie un digest vide

L’exécution de la tâche en ligne avec :

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

produit le même résultat – aucune nouvelle ligne EmailLog n’est créée.

Cause possible :

Il semble que le digest soit ignoré en raison d’une condition de “digest vide” – peut-être quelque chose a-t-il changé dans la façon dont Discourse 3.6 évalue le contenu à inclure. La vue Admin → Emails → Test de digest rend le digest correctement, mais la tâche d’arrière-plan ne voit rien à inclure.

Résumé :

:white_check_mark: Utilisateur éligible

:white_check_mark: Email actif + SMTP valide

:white_check_mark: Le test de digest de l’administrateur s’affiche correctement

:prohibited: La tâche de digest d’arrière-plan s’ignore silencieusement (digest vide)

:prohibited: Aucune tentative d’enregistrement EmailLog ou d’envoi enregistrée

J’aimerais une confirmation de l’équipe – y a-t-il potentiellement une régression dans la façon dont UserNotifications.digest collecte le contenu dans la version 3.6 ?

5

En effectuant un peu plus de travail ici, nous avons trouvé une poignée (sur 4 000) d’utilisateurs qui reçoivent effectivement les résumés d’activité de manière fiable.

La comparaison d’un de ces utilisateurs qui reçoit des résumés avec un autre qui n’en reçoit pas ne montre aucune différence dans leurs paramètres.

===== xxxxx (ID : 4149) =====
Actif : true, Suspendu : false, Silencieux : false
Email confirmé : false
Digest activé : true
Fréquence du digest : 10080 minutes
Dernière connexion : 2025-03-24 20:58:55 UTC
Dernier email envoyé : 2025-10-16 17:07:53 UTC
Catégories mises en sourdine :
Tentative de digest des statistiques utilisateur : 2025-10-16 17:07:53 UTC
Total d’emails envoyés : 16
===== xxxxxxx (ID : 42206) =====
Actif : true, Suspendu : false, Silencieux : false
Email confirmé : false
Digest activé : true
Fréquence du digest : 10080 minutes
Dernière connexion : 2025-09-14 15:52:54 UTC
Dernier email envoyé : 2025-10-01 23:30:33 UTC
Catégories mises en sourdine :
Tentative de digest des statistiques utilisateur : 2025-10-16 17:32:34 UTC
Total d’emails envoyés : 2

Il y a certainement d’autres paramètres, mais je pensais que c’était une comparaison intéressante quoi qu’il en soit.

7

Quelqu’un peut-il fournir une commande Rails que nous pouvons exécuter pour vérifier combien de digests / résumés d’activité sont réellement en retard ? Essentiellement, une vérification de l’intégrité indiquant que le système envoie effectivement les résumés comme prévu.

8

Vous pouvez essayer la requête ci-dessous dans la console Rails, les utilisateurs actifs qui ont activé les e-mails récapitulatifs et qui sont dus pour leur prochain e-mail récapitulatif

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

Est-il possible que le résumé soit ignoré parce que l’utilisateur n’a pas visité pour Supprimer l'e-mail de résumé après des jours ?

10

@jahan_gagan c’est utile, mais cela nous dira qui va recevoir un résumé d’activité/un résumé, mais pas qui n’a PAS reçu son résumé d’activité. Est-ce que cela a du sens ? La question est de savoir comment voir qui NE reçoit PAS le résumé qu’il devrait recevoir.

11

@Moin nous l’avons réglé sur 0 - cela ne devrait donc pas être un facteur.

12

Êtes-vous sûr que 0 désactive cela ? Avez-vous essayé un grand nombre à la place ?

13

@Moin Merci, je l’ai changé à 3000 - aucun changement dans le résumé envoyé. Je vois toujours des centaines avec la fréquence hebdomadaire (maintenant plus de deux semaines) sans être envoyés.

14

D’accord, voici un test pour voir qui est éligible actuellement :

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

Nous allons forcer un envoi maintenant, et rien n’est envoyé…

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

Prenons un utilisateur exemple qui ne reçoit pas le résumé, et vérifions l’interface d’administration, et il semble pleinement éligible…

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

16

Alors, par manque d’autres idées, nous avons changé la fréquence des résumés à quotidienne pour tous les utilisateurs via l’administration, à 1440.

Et soudain, tous les résumés ont été envoyés…

Quelqu’un a-t-il une idée pourquoi ? Changer la fréquence n’aurait dû avoir aucun impact étant donné que nous pouvons voir que ces utilisateurs étaient éligibles avec la fréquence hebdomadaire.

17

Je me suis emporté trop vite, le changement de fréquence a fonctionné pour un groupe d’utilisateurs (un site) mais pas pour un autre, cela n’a rien changé. Le mystère continue…

18

Je pense que cela pourrait être dû à l’une des dernières exigences dans la requête que j’ai liée ci-dessus.

Après avoir vérifié que l’utilisateur est réel, activé, non mis en scène et non suspendu, et vérifié qu’il n’a pas désactivé les résumés et que la fréquence est supérieure à 0, qu’il y a un e-mail principal et que le score de rebond est correct, il y a des vérifications basées sur le temps :

Dernière connexion il y a plus de digest_after_minutes minutes
Dernière connexion dans les suppress_digest_email_after_days jours
La dernière vérification si l’utilisateur doit recevoir un résumé date d’il y a digest_after_minutes minutes.

Je pense que ce dernier point pourrait être la cause. Si Discourse a essayé d’envoyer le résumé hier et que digest_after_minutes est d’une semaine, alors il n’essaiera pas avant une semaine. Si vous réduisez cela, la prochaine tentative se produira plus tôt.

1 « J'aime »
19

@Jacob_Peebles on dirait que vous avez du mal avec ça depuis un bon moment ! Je pense que Digest Emails Not Sending to All Users – Need Help Debugging en mars concerne le même problème, n’est-ce pas ?

Le dernier message de Moin vous a-t-il aidé ? Si oui, faites-le nous savoir afin que nous puissions clore ce sujet.