J’ai l’impression que depuis ma dernière mise à jour de Discourse il y a quelques jours, l’e-mail de réponse ne fonctionne plus, il n’est pas reçu et donc ne met pas à jour le sujet, et l’e-mail envoyé pour les catégories surveillées se comporte également mal, n’envoyant que 5 sur 65.
Quelqu’un d’autre a-t-il des problèmes d’e-mail récents ?
Oui, j’ai malheureusement les mêmes problèmes avec la version 3.4.0.beta4-dev. J’ai tout essayé, de la réévaluation du fichier app.yml à la vérification des paramètres DNS du courrier. Ironiquement, depuis le terminal, j’ai pu envoyer via smtp dans le conteneur Docker de Discourse en utilisant wasm. Ce qui, je pense, pourrait provenir d’un bug de configuration quelque part. C’est un gros problème pour tous les utilisateurs enregistrés qui ne peuvent pas recevoir d’e-mails pour les publications, les newsletters, la réinitialisation de mot de passe. Le message d’erreur 550 est présent depuis la nouvelle mise à jour. Maintenant, je prie pour que le retour à la version v3.4.0.beta2 résolve ce bug.
Je suis content que ce ne soit pas juste moi, j’espère que des développeurs corrigeront ce problème dès que possible. Je n’ai aucune idée de comment revenir en arrière.
Installé
3.4.0.beta4-dev
58f75ed205
Il y a également eu une mise à jour de la base de données postgres de la version 13 à la version 15 qui a eu lieu en même temps.
Je ne sais pas si la mise à jour de postgres a perturbé la configuration des paramètres depuis l’interface graphique, car j’ai remarqué que l’ajout d’informations sur le serveur POP3 pour l’interrogation n’a entraîné aucun changement dans le fichier de configuration app.yml de discourse… très étrange. Le retour arrière est un peu délicat car il vous oblige à accéder aux balises git et à reconstruire toute l’application à partir des versions. Utiliser chatGPT pour cela peut aider au dépannage.
Avez-vous réussi à le faire fonctionner en revenant à une version précédente ?
J’espère que l’équipe de développement s’en occupera très bientôt et créera un correctif pour l’avenir.
J’ai essayé git checkout v3.4.0.beta2 dans le docker mais j’ai échoué plusieurs fois à revenir en arrière malgré la spécification du fichier app.yml. Je vais donc voir s’il y a une personne à contacter chez Discourse pour corriger ce bug d’erreur 550 pour beta5 bientôt.
Où voyez-vous cette erreur ? J’ai juste de gros problèmes avec les e-mails, mais je ne suis pas sûr de voir le 550 err, merci.
Je ne vois aucune erreur dans les journaux d’e-mails via l’interface graphique, seulement les réponses ne sont pas reçues et les e-mails envoyés ne vont qu’à quelques personnes, alors qu’ils devraient aller à environ 65 personnes.
Je vois ceci dans /logs :
Veuillez ne pas @mentionner les membres de l’équipe.
Si vous êtes un client Discourse payant, vous pouvez obtenir un support prioritaire en contactant team@discourse.org, sinon, il s’agit d’un support au mieux de nos capacités.
Lorsque vous signalez un problème, veuillez spécifier quel fournisseur de messagerie vous utilisez, peut-être que quelque chose a régressé sur un fournisseur de messagerie couramment utilisé pour Discourse. Je ne sais pas.
Je suis vraiment désolé, je ne m’en étais pas rendu compte, je ne le ferai plus. Merci de me l’avoir signalé concernant les mentions.
J’utilise Brevo, mais je ne pense pas que cela soit lié à Brevo d’après ce que je vois, car certains e-mails sont envoyés.
Les réponses arrivent via Gmail, mais cela a toujours fonctionné.
Peut-être que l’autre personne qui répond pourra nous dire ce qu’elle utilise. Elle a le même problème.
C’est sous les journaux de serveur et les rapports. Peut envoyer un e-mail de test et renverra une erreur de courrier 550 dans l’onglet Ignoré. Je n’ai rien entendu de la part des développeurs. Je pense qu’avec la mise à jour de PostGres 15, les paramètres n’ont peut-être pas été transférés à la base de données pour s’exécuter si app.yml nécessite une communication.
Je peux envoyer un e-mail de test avec succès, sans erreur. Cet e-mail de test est envoyé via Brevo.
Le problème pour moi est que les e-mails de la catégorie surveillée n’arrivent qu’à quelques utilisateurs. Les e-mails manquants n’apparaissent pas comme ignorés. La majorité des utilisateurs ne reçoivent tout simplement pas les e-mails.
Le deuxième problème est que les e-mails de réponse n’arrivent jamais dans le système.
Ces problèmes n’ont commencé qu’après la récente mise à niveau.
Je suis sous Ubuntu 22.04, qui a également eu une mise à niveau de conteneur récemment, mais je n’ai remarqué le problème de messagerie qu’après avoir mis à jour Discourse, ce qui a bien sûr également mis à jour Postgres.
Quel système d’exploitation utilisez-vous, Phil ?
cela apparaît souvent dans le journal de production :
Email can not be processed: Email::Receiver::EmptyEmailError
tail -1000 production.log-20250202 | grep ‘Email::Receiver::EmptyEmailError’ | wc -l
291
Je vois ce sujet, mais je ne comprends pas la solution, quelqu’un peut-il me l’expliquer s’il vous plaît ? Où se trouve la boîte de réception ? Je peux voir ma boîte de réception si je clique sur messages deux fois pour mon compte, et je peux supprimer ces messages, mais il n’y en a pas beaucoup. Donc, je veux dire comment puis-je voir tous les e-mails de réponse entrants, quelle boîte de réception, etc.
Lorsque vous cliquez sur l’erreur, voyez-vous plus de détails ? Il pourrait très bien s’agir d’un seul e-mail mal / mal formaté et nous continuons à reprogrammer le travail qui est censé le traiter.
Remarque : je viens de publier sur un sujet qui aurait dû créer 65 e-mails, mais il n’en a créé que 5 dans les messages envoyés, rien n’a été ignoré, etc. Aucune erreur et aucun avertissement.
Il y a une erreur dans /logs d’hier, et un avertissement, je ne sais pas s’ils sont liés à mes problèmes d’e-mail :
Message (552 copies signalées)
Job exception : Net::ReadTimeout
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:229:in `rbuf_fill'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:199:in `readuntil'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:377:in `each_message_chunk'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:958:in `block in retr'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:1016:in `critical'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:956:in `retr'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:810:in `pop'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:47:in `block (2 levels) in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:46:in `block in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:45:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/app/jobs/base.rb:379:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:137:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:77:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:63:in `block (2 levels) in ensure_worker_threads'
Message (694 copies signalées)
Email cannot be processed : Email::Receiver::EmptyEmailError
Backtrace
/var/www/discourse/vendor/bundle/ruby/7.2.2.1/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `block in warn'
/var/www/discourse/vendor/bundle/ruby/7.2.2.1/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/7.2.2.1/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `each'
/var/www/discourse/vendor/bundle/ruby/7.2.2.1/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/7.2.2.1/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `warn'
/var/www/discourse/lib/email/processor.rb:183:in `log_email_process_failure'
/var/www/discourse/lib/email/processor.rb:29:in `rescue in process!'
/var/www/discourse/lib/email/processor.rb:16:in `process!'
/var/www/discourse/lib/email/processor.rb:13:in `process!'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:29:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:49:in `block (2 levels) in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:46:in `block in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:45:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/6.1.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/app/jobs/base.rb:379:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:137:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:77:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:63:in `block (2 levels) in ensure_worker_threads'
Comment savez-vous qu’il aurait dû créer 65 e-mails ?
Je sais exactement qui a configuré des catégories surveillées, et ceci est une catégorie surveillée, et aucun utilisateur n’a désactivé les notifications. Cela devrait absolument envoyer 65 e-mails, comme cela l’a toujours fait avant la mise à jour.
Je vais mettre à jour vers la nouvelle version plus tard aujourd’hui et voir si cela fait une différence, de 3.4.0.beta4-dev à la nouvelle version.
Je vais également redémarrer la VM, je suppose que cela redémarrerait gracieusement la base de données, qui, soit dit en passant, s’est correctement installée conformément à la documentation lors de la mise à jour vers 3.4.0.beta4-dev.
Outre ce que j’ai déjà mentionné, comme les mises à jour du système d’exploitation Ubuntu22.04 pour containerd, je ne penserais pas que ce serait un problème, mais le seul autre changement que j’ai apporté la semaine dernière est l’installation du plugin CakeDay.