Nous avons migré depuis une liste de diffusion et de nombreux utilisateurs utilisent encore notre forum principalement par e-mail.
Il y a environ 300 utilisateurs en mode liste de diffusion. Cependant, Discourse ne semble envoyer que 75 à 80 e-mails lorsqu’un nouveau sujet est ajouté.
J’ai comparé les paramètres de liste de diffusion de divers membres et ils sont identiques.
Rien n’apparaît dans la section ignorée.
Je ne sais pas où chercher pour identifier la cause de ce problème.
Tous les utilisateurs sont-ils activés ? Peut-être ne reçoivent-ils aucun e-mail ?
Oui, tout cela est activé.
Cela semble également aléatoire, malheureusement. J’ai plusieurs comptes que j’utilise pour configurer des éléments et ils se comportent différemment.
J’ai maintenant consulté quelques anciens sujets ici et cela semble similaire : https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
Cela pourrait être le même problème. Cependant, je ne sais pas comment modifier les paramètres comme suggéré dans la solution de ce post.
J’essaie d’exécuter ceci :
User.find_by_username(‘Neuer.test’).mailing_list_mode
mais j’obtiens :
NoMethodError: méthode non définie `mailing_list_mode’ pour #User:0x00005569c4038af8
Le mode liste de diffusion est défini dans la table user_options. Essayez d’exécuter UserOption.where(mailing_list_mode: true). Pour obtenir les identifiants des utilisateurs ayant le mode liste de diffusion activé, exécutez UserOption.where(mailing_list_mode: true).pluck(:user_id)
Merci @simon
J’ai généré une liste comme suggéré dans votre message. Il s’agit en fait de plusieurs listes. Elle génère une liste d’identifiants d’utilisateur, puis atteint environ 50 entrées, affiche :...skipping..., puis recommence avec les mêmes identifiants d’utilisateur, en ajoutant un nouvel élément en bas, et répète ce processus environ 4 ou 5 fois. Entre-temps, il y a une section entière composée uniquement de lignes vides. Mais cela pourrait être un comportement normal ?
En tout cas, cela est loin de constituer une liste complète des utilisateurs abonnés via le mode liste de diffusion (seulement 58, alors que j’attends environ 350).
J’ai ensuite effectué quelques vérifications sur les identifiants et aucun d’entre eux n’a reçu le dernier message, par exemple.
J’ai également exécuté UserOption.where(mailing_list_mode: false).pluck(:user_id), ce qui a donné 29 autres entrées.
L’exécution de UserOption.where(mailing_list_mode: 1).pluck(:user_id) a donné un nombre similaire à true et les mêmes utilisateurs.
Au total, j’ai seulement trouvé environ 90 des 400 utilisateurs activés. Tout cela est très étrange et je ne comprends pas ce qui se passe.
Toute aide serait grandement appréciée.
P.S. Comment quitter après le dernier : en bas des résultats de recherche, afin de pouvoir exécuter une autre requête ?
Lorsque la requête renvoie plus de texte que ce qui peut tenir à l’écran, elle l’affiche de manière réduite. Vous pouvez chercher sur Google comment cela fonctionne.
La barre d’espace permet d’accéder à l’écran suivant, / pour rechercher et q pour quitter.
Donc, je pense que cela signifie que vous recevez des courriers destinés aux utilisateurs actifs. Les autres pourraient-ils être inactifs ?
Merci, Jay.
Non, nous avons plus de 450 utilisateurs actifs. Je ne vois pas vraiment de modèle ; j’ai consulté un ancien message d’il y a quelques jours qui a été envoyé à 334 utilisateurs via le mode liste de diffusion.
La seule chose qui a changé depuis, c’est que nous avons ajouté un enregistrement SPF à notre DNS, car nous rencontrions des problèmes d’envoi vers Google. Mais cela concernait notre serveur de messagerie ; je n’ai modifié aucun des paramètres SMTP dans Discourse.
@pfaffman Je viens d’installer Data Explorer ; peut-être existe-t-il une requête que je pourrais exécuter directement là-bas ?
Cela commence à me mettre la tête à l’envers 
J’allais poster pour dire que, d’une manière ou d’une autre, tout semblait s’être « résolu » tout seul, puisque 336 personnes ont reçu divers messages récents.
Puis sont arrivées deux réponses à un message en succession rapide, toutes deux par le même utilisateur. 181 membres ont reçu les deux messages, 38 n’en ont reçu qu’un seul, laissant 117 sans aucun e-mail.
Y a-t-il un autre journal quelque part où je pourrais regarder pour éclaircir cette situation ? Il n’y a rien dans Sidekiq.
Le problème semble être une erreur 421.4.7.0 : trop de connexions depuis l’adresse IP.
Étrangement, cela semble se produire principalement avec un seul membre.
Comment puis-je résoudre ce problème ?
Voici ce que disent les journaux :
Message (1957 copies signalées)
Exception de tâche : 421 4.7.0 dd27022.xxxxxx.com Erreur : trop de connexions depuis xxx.xxx.xx.xxx
### Backtrace
/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'
Vous devrez vous renseigner auprès de votre fournisseur de messagerie, cela n’a rien à voir avec Discourse.
@codinghorror
J’ai donc changé de fournisseur de messagerie et j’utilise désormais Amazon SES. Cela semblait avoir résolu le problème pendant quelques semaines. Maintenant, Discourse a recommencé à arrêter aléatoirement l’envoi de courriels en cours de livraison aux abonnés de la liste de diffusion. Aucune erreur dans les journaux. J’ai reconstruit le conteneur et pour l’instant, tout semble à nouveau correct. Y a-t-il un autre endroit où je pourrais chercher un journal d’erreur potentiel ?
Des tâches sont-elles bloquées dans Sidekiq ?
Non, malheureusement, il n’y en a pas.
Je rencontre un problème similaire depuis quelques jours. Les e-mails ne sont pas envoyés aux utilisateurs de la liste de diffusion, aucun travail n’est en attente dans Sidekiq, et je reçois la même erreur dans les journaux. J’ai essayé de reconstruire, mais cela ne semble pas faire de différence. Cela cause vraiment beaucoup de détresse à nos utilisateurs.
Ce qui semble se passer, c’est qu’après une reconstruction, si un nouveau message est reçu, il est envoyé, mais aucun message ou réponse ultérieur n’est envoyé après cela.
Toute aide serait très appréciée !
Ed
Cela devient vraiment frustrant pour moi.
Aujourd’hui, Discourse a décidé d’arrêter l’envoi aux abonnés de la liste de diffusion après avoir seulement livré 15 e-mails. Ce n’est pas un problème de fournisseur, car j’ai déjà changé de fournisseur. Il n’y a également aucun message d’erreur dans les journaux ni rien de bloqué dans Sidekiq.
Je pense que la seule solution semble être une reconstruction.
Existe-t-il un moyen de planifier automatiquement une reconstruction à intervalles réguliers ? Au moins, je n’aurai pas besoin de la surveiller constamment.
Vous pourriez configurer une tâche cron pour cela.
Certains utilisateurs n’ont-ils pas atteint la limite d’emails par jour ? Ont-ils désactivé les emails ? (cela n’expliquerait pas pourquoi une reconstruction résoudrait le problème). Avez-vous suffisamment de RAM ? Y a-t-il quelque chose dans les journaux ?
Mémoire insuffisante est un message d’erreur assez clair.
MODIF : Oups. Je vous ai confondu avec un autre sujet, donc tout ce qui concerne le multisite, bien que vrai, peut ne pas avoir de sens ici.
Je suis presque certain que mon instance réservée au multisite fonctionne avec 4 Go de RAM, mais cela n’inclut pas MySQL, Apache et WordPress. Mon site avec (staging + production)*(discourse + wordpress) m’a posé des problèmes avant que je ne passe à 8 Go. Cela inclut des conteneurs pour PostgreSQL, Redis, Traefik, Prometheus et MariaDB, plus deux instances chacun pour WordPress et Discourse (pas de multisite, car la version de test doit pouvoir avoir des plugins différents de la version de production).
Si économiser de l’argent est votre priorité et que vous avez des sites Discourse à faible volume, il est probablement préférable d’utiliser un droplet séparé de 5 $ (1 Go) pour chacun.
Oui, je m’en doutais 
Je suis sur un CPU partagé standard et j’exécute un seul site Discourse sur mon droplet.