Qu'est-ce qui pourrait causer la non-envoi de certains messages en mode liste de diffusion

Soutien
1

Sur une version auto-hébergée actuelle de Discourse, j’ai des sujets où les publications ne sont pas envoyées à certains utilisateurs qui ont choisi de recevoir toutes les publications par e-mail en mode liste de diffusion.

J’ai vérifié mes journaux d’e-mails, il y a bien des e-mails envoyés pour les publications de ce sujet à certains utilisateurs mais pas à d’autres qui ont également choisi de recevoir des e-mails pour toutes les publications ; l’un de mes comptes utilisateur de test les reçoit, mais pas un autre compte utilisateur de test.

J’ai essayé de publier dans le sujet plusieurs fois, tout comme au moins une autre personne.

Je ne vois aucun paramètre de site ou d’utilisateur qui pourrait causer cela, qu’est-ce que je ne vois pas ?

Ce sont les publications :

  id   | user_id |          timezone
--------+---------+----------------------------
 119197 |     586 | 2023-04-03 11:05:41
 119198 |       2 | 2023-04-03 11:12:03.207053
 119215 |       2 | 2023-04-03 15:42:45.195223
 119216 |       2 | 2023-04-03 16:18:22.664227
 119218 |     508 | 2023-04-03 16:55:42.167977
 119219 |       2 | 2023-04-03 16:56:00.140777
 119222 |       2 | 2023-04-03 18:11:33.953314
(7 rows)

Ce sont les e-mails envoyés à l’utilisateur 703 (de la table email_logs)

 id  | post_id |  email_type  |          timezone          |      smtp_transaction_response
-----+---------+--------------+----------------------------+--------------------------------------
 242 |  119197 | mailing_list | 2023-04-03 11:18:55.832126 | 250 2.0.0 Ok: queued as C95C443350B8
 243 |  119198 | mailing_list | 2023-04-03 11:22:04.731579 | 250 2.0.0 Ok: queued as B0E2943350B8
(2 rows)

Ce sont tous les e-mails envoyés pour ces publications :

 id  | post_id |  email_type  | user_id |          timezone          |      smtp_transaction_response
-----+---------+--------------+---------+----------------------------+--------------------------------------
 242 |  119197 | mailing_list |     703 | 2023-04-03 11:18:55.832126 | 250 2.0.0 Ok: queued as C95C443350B8
 243 |  119198 | mailing_list |     703 | 2023-04-03 11:22:04.731579 | 250 2.0.0 Ok: queued as B0E2943350B8
 276 |  119215 | mailing_list |       5 | 2023-04-03 15:52:47.834189 | 250 2.0.0 Ok: queued as B51B443350B8
 277 |  119216 | mailing_list |       5 | 2023-04-03 16:28:29.651872 | 250 2.0.0 Ok: queued as 8760743350B8
 281 |  119218 | mailing_list |       5 | 2023-04-03 17:05:43.582886 | 250 2.0.0 Ok: queued as 8209143350B8
 282 |  119219 | mailing_list |       5 | 2023-04-03 17:06:02.231359 | 250 2.0.0 Ok: queued as 201A243350B8
 287 |  119222 | user_replied |     508 | 2023-04-03 18:21:38.024441 | 250 2.0.0 Ok: queued as EDE47434362C
 288 |  119222 | mailing_list |       5 | 2023-04-03 18:21:38.074723 | 250 2.0.0 Ok: queued as 07474434362D
(8 rows)

L’ID utilisateur 5 n’a été ajouté à la liste des utilisateurs copiés qu’après que j’ai remarqué le problème sur un autre sujet.

Cela semble se produire sur près de la moitié des sujets/publications d’aujourd’hui. Ce système vient d’être mis en ligne hier, mais je n’ai rien vu de tel pendant les tests.

2

J’ai essayé de définir le nombre maximal d’e-mails par utilisateur et par jour à 0 pour le désactiver, bien qu’il ait été précédemment à 100, ce qu’il ne semble pas avoir atteint.

Mise à jour : Cela n’a pas résolu le problème.

Ne devrait-il pas enregistrer quelque part la raison pour laquelle l’e-mail n’a pas été envoyé ?

3

Oui : Paramètres → Journaux → Journaux d’erreurs

4

Rien dans le journal d’erreurs à ce sujet, ni quoi que ce soit près des horodatages auxquels les e-mails manquants auraient dû être envoyés.

Cela pourrait-il être un problème de Sidekiq ? J’ai beaucoup de messages indiquant que Sidekiq utilise trop de mémoire aujourd’hui.

5

Il semble que le sujet soit confus, une fois qu’un message dans ce sujet n’est pas envoyé à cet utilisateur, aucun message futur n’est envoyé à cet utilisateur non plus.

6

Il semble que topic_user.notification_level ait été défini sur 0 (silencieux ?) pour cet utilisateur/sujet, et il ne semble pas y avoir de moyen de le rétablir à 1 depuis les écrans d’administration, bien que cela puisse probablement être fait avec rails. Mais comment a-t-il été modifié ?

Cela aurait-il pu résulter de quelqu’un cliquant sur le lien « se désabonner » dans l’e-mail, avant que je ne trouve comment le supprimer des e-mails envoyés au serveur relais ? Si c’est le cas, ne devrait-il pas y avoir un moyen d’annuler cela ?

7

La suppression de toutes les balises dans les deux sujets concernés ou la définition de la notification sur autre chose que “muet” ne semble pas avoir modifié topic_users.

Aucun sujet muet n’apparaît dans le profil de cet utilisateur.

Je ne suis pas sûr de vouloir simplement modifier tous les sujets en bloc, voici le décompte des valeurs de notification_level dans topic_users :

 notification_level | count
--------------------+--------
                  0 |      2
                  1 |    177
                  2 |     45
                  3 | 119818
8

Ouais, j’ai enfin trouvé où désactiver le son de ces sujets pour cet utilisateur !

J’ai dû remarquer qu’il y avait une balise ‘show’ au-dessus de la boîte muette dans la colonne de gauche de la page de suivi pour cet utilisateur.

9

N’ont-ils pas volontairement mis ce sujet en sourdine et ne souhaitent-ils pas recevoir de notifications/e-mails à ce sujet ?

10

Non, car il s’agissait essentiellement d’un compte de personnel que j’avais configuré dans le but exprès de transférer des publications d’un groupe vers une liste de diffusion externe héritée, et pour autant que je sache, je n’ai jamais intentionnellement mis cet utilisateur en sourdine sur ce sujet.

Mais au moins, j’ai beaucoup appris sur la structure des données, j’ai lu du code Ruby et j’ai appris quelques notions sur l’administration. :wink:

Je pense que ce sujet peut être clos maintenant.