Je ne suis pas l’administrateur système de l’instance AWS EC2 hébergeant notre instance Discourse, mais je suis l’administrateur de l’instance Discourse elle-même. Nous avons eu un arrêt du service de messagerie AWS SES il y a 3 semaines pour des raisons de sécurité. Notre personnel cloud ne le répare que maintenant. Donc, pendant 3 semaines, notre site n’a pas pu envoyer d’e-mails et je vois plus de 40 000 tâches échouées et autant de tentatives. Je ne suis pas un développeur web, donc je ne comprends pas ce que la page Sidekiq me dit, mais je crains que les tâches échouées ne soient retentées lorsque notre serveur de messagerie sera de nouveau en ligne, submergeant les gens d’e-mails obsolètes qu’ils n’ont pas reçus depuis 3 semaines. Sera-ce le cas ? Discourse renvoie-t-il les e-mails qui n’ont pas pu être envoyés en raison d’un serveur de messagerie hors ligne ? Si oui, comment puis-je désactiver cela pour éviter de submerger les gens avec des e-mails de notre site ? Pouvons-nous ajuster la granularité ? Par exemple, n’envoyer que les e-mails montrant les nouvelles activités depuis une date donnée ?
Votre peur est légitime.
Je ne suis pas sûr du temps dont vous disposez pour résoudre ce problème ? Une solution pourrait être de configurer un serveur de messagerie qui accepte les e-mails mais les supprime simplement.
La manière vraiment rapide et (très) sale de résoudre ce problème est d’utiliser redis-cli et d’exécuter une commande flushdb. Cela supprimera toutes les tâches mises en file d’attente. Cela déconnectera également tous les utilisateurs. Redémarrez ensuite votre Discourse pour vous assurer que toutes les tâches régulières s’exécutent à nouveau.
La déconnexion de tous les utilisateurs n’est certainement pas souhaitable… Le serveur de messagerie devrait être réparé aujourd’hui, mais je ne suis pas sûr que nos administrateurs système auront la flexibilité nécessaire pour configurer le serveur de messagerie afin qu’il supprime tout.
Je vois un bouton « tout tuer » et « tout supprimer » en bas de la page « retries » de sidekiq (voir ci-joint). Est-ce que cela peut aider ?
La suppression de tous les travaux de la file d’attente d’un certain type devrait faire l’affaire.
(Je devrais revenir en arrière et essayer de trouver comment faire cela…)
Je pense que vous êtes sûr. Ils ont mis trois semaines à le réparer.
Vous pourriez demander s’ils peuvent chercher sur Google comment purger les tâches de sidekiq et supprimer les tâches de messagerie. Je pense que c’est votre meilleure option.
Je suppose que vous n’avez pas accès pour le faire vous-même ou pour engager quelqu’un pour vous aider. Pouvez-vous vous connecter en SSH à l’ec2 sur lequel il s’exécute ? Vous pourriez essayer de supprimer les 50 000 de l’interface web.
La page de l’assistant avec les options de suppression/destruction fonctionnait. Aucun administrateur système EC2 n’était nécessaire, être administrateur du forum suffisait pour opérer depuis la page de l’assistant, je pouvais supprimer tous les e-mails mis en file d’attente.
Après que le serveur de messagerie a été de nouveau en ligne, aucun e-mail “mis en file d’attente” n’a été renvoyé.