Je constate que le serveur a envoyé avec succès un grand nombre d’e-mails pour ce nouveau sujet à tous ceux qui suivaient cette catégorie. Je ne vois aucune erreur dans les journaux d’e-mails ni sur le serveur d’e-mails.
J’ai également remarqué les journaux de discourse :
Message (21 copies signalées)
Exception de tâche : Échec de la validation : Le message a déjà été pris
Backtrace
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/validations.rb:80:in `raise_validation_error'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/validations.rb:53:in `save!'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/transactions.rb:302:in `block in save!'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/connection_adapters/abstract/database_statements.rb:318:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/transactions.rb:350:in `with_transaction_returning_status'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/transactions.rb:302:in `save!'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/suppressor.rb:48:in `save!'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/persistence.rb:55:in `create!'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation.rb:799:in `_create!'
Pour cette entrée, oui, elle était toujours bloquée dans une boucle de nouvelle tentative jusqu’à hier, date à laquelle, après des centaines de nouvelles tentatives, j’en ai eu marre et je l’ai supprimée. J’espère que je n’ai rien cassé.
Je ne l’ai pas revue, mais il n’y a pas eu d’événement qui ait déclenché des centaines d’e-mails sur un seul article. Ce serait bien cependant de comprendre d’où cela vient et ce que cela signifie.
Il y a quelques jours, j’ai vu cette erreur sur trois messages, et ils n’étaient pas critiques, j’ai donc supprimé les tâches après qu’une nouvelle tentative n’ait pas abouti.
Maintenant, j’en ai 2001, et mon compte de test n’a pas reçu un résumé hebdomadaire qu’il aurait dû recevoir.
J’ai mis à jour vers bf987af3ca et j’ai tout réessayé et j’ai toujours au moins 38 Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RecordInvalid: Validation failed: Post has already been taken qui s’affichent dans ma console sidekiq.
Sans autres mises à jour, il m’en reste maintenant 30. Je suppose qu’ils expirent, sauf que mon compte de test a reçu le résumé hebdomadaire (retardé), et je suppose que c’est lié. Je ne sais pas où chercher dans les journaux pour savoir si certains abandonnent réellement.
Ils semblent échouer la plupart du temps mais réussir occasionnellement, ce qui ressemble vraiment à une condition de concurrence quelque part.
Mes backtraces ressemblent à ce que @RBoy et @md-misko ont vu, mais voici la backtrace complète, pas seulement celle tronquée du bouton “Copier” :
activerecord-7.0.3/lib/active_record/validations.rb:80:in `raise_validation_error'
activerecord-7.0.3/lib/active_record/validations.rb:53:in `save!'
activerecord-7.0.3/lib/active_record/transactions.rb:302:in `block in save!'
activerecord-7.0.3/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:314:in `transaction'
activerecord-7.0.3/lib/active_record/transactions.rb:350:in `with_transaction_returning_status'
activerecord-7.0.3/lib/active_record/transactions.rb:302:in `save!'
activerecord-7.0.3/lib/active_record/suppressor.rb:54:in `save!'
activerecord-7.0.3/lib/active_record/persistence.rb:55:in `create!'
activerecord-7.0.3/lib/active_record/relation.rb:869:in `_create!'
activerecord-7.0.3/lib/active_record/relation.rb:115:in `block in create!'
activerecord-7.0.3/lib/active_record/relation.rb:880:in `_scoping'
activerecord-7.0.3/lib/active_record/relation.rb:428:in `scoping'
activerecord-7.0.3/lib/active_record/relation.rb:115:in `create!'
activerecord-7.0.3/lib/active_record/relation.rb:219:in `block in create_or_find_by!'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
activerecord-7.0.3/lib/active_record/transactions.rb:209:in `transaction'
activerecord-7.0.3/lib/active_record/relation/delegation.rb:67:in `block in transaction'
activerecord-7.0.3/lib/active_record/relation.rb:880:in `_scoping'
activerecord-7.0.3/lib/active_record/relation.rb:428:in `scoping'
activerecord-7.0.3/lib/active_record/relation/delegation.rb:67:in `transaction'
activerecord-7.0.3/lib/active_record/relation.rb:219:in `create_or_find_by!'
activerecord-7.0.3/lib/active_record/querying.rb:22:in `create_or_find_by!'
/var/www/discourse/lib/email/sender.rb:498:in `get_reply_key'
/var/www/discourse/lib/email/sender.rb:105:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:83:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:38:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
/var/www/discourse/lib/rails_multisite/connection_management.rb:80: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.4.2/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.4.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.4.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.4.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.4.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.4.2/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.4.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_retry.rb:114:in `local'
sidekiq-6.4.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq.rb:40:in `block in <module:Sidekiq>'
sidekiq-6.4.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.4.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.4.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_retry.rb:81:in `global'
sidekiq-6.4.2/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_logger.rb:39:in `prepare'
sidekiq-6.4.2/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.4.2/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.4.2/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.4.2/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.4.2/lib/sidekiq/util.rb:56:in `watchdog'
sidekiq-6.4.2/lib/sidekiq/util.rb:65:in `block in safe_thread'
Y a-t-il d’autres informations que je pourrais fournir pour aider au débogage ?
4 « J'aime »
RGJ
(Richard - Communiteq)
A scindé ce sujet ()
16
J’ai découvert que mon serveur de messagerie utilisait un certificat pour un autre serveur dans son round-robin, et j’espérais que l’inadéquation du nom d’hôte était le problème. J’ai mis à jour vers b850c12793 dans le processus de changement vers un serveur qui n’avait pas d’inadéquation de certificat, mais cela n’a pas résolu le problème. J’ai retenté certains des travaux, mais aucun d’entre eux ne s’est terminé avec succès. Par conséquent, ce bug n’est pas le symptôme d’inadéquations de certificats cachées.
Ceci a été construit avec discourse_docker 2a9faf7e5680b9.
La mise à jour de discourse_docker vers 241a42ce718, et avec elle discourse vers 95e7e10417, n’a pas non plus résolu le problème. J’ai toujours 30 de ces échecs en cours de nouvelle tentative.
D’après ce que vous décrivez et en examinant ce post, il pourrait y avoir plusieurs problèmes ici :
Le serveur ne limite peut-être pas ses tentatives de renvoi d’e-mails, ce qui entraîne un délai d’attente ou un rejet par le serveur de messagerie. Mais il y a un autre problème sous-jacent si vos certificats et votre configuration sont valides et que les e-mails ne sont toujours pas envoyés. Pour certains, cela semble également consommer de l’espace disque. J’ai vérifié le mien mais je n’ai pas remarqué cela ici.
Je n’ai pas manqué d’espace, et cela se produit même lorsque je sélectionne un seul travail à relancer, donc cela ne ressemble pas à une condition de concurrence. Il y a clairement plus d’un problème ici, et ce que je vois ici n’est pas lié à ce sujet lié.
(Il s’avère que je n’avais pas de problème de certificat après tout ; les noms de serveur étaient dans le nom de serveur alternatif. Mais je suis passé à l’utilisation du nom d’hôte qui correspond au SN de toute façon, et cela n’a fait aucune différence.)
J’envoie avec succès un nombre énorme de courriels, seuls ces quelques travaux sont bloqués. Je ne sais pas, par exemple, quelles entrées de journal rechercher pour aider au diagnostic.
J’ai examiné mes 29 e-mails échoués pour m’assurer qu’il n’y avait rien de critique à envoyer, et d’après ce que j’ai pu constater, il n’y en avait pas, j’ai donc supprimé tous les travaux dans sidekiq, au cas où cela serait dû à un problème transitoire dû à des travaux d’e-mails couvrant des mises à niveau. Cependant, sans appliquer d’autres mises à niveau, j’ai maintenant un autre cas de la même défaillance.
Je partage cela simplement comme information indiquant qu’il s’agit d’un problème persistant et non d’un problème transitoire étrange.
La correction de code ci-dessus a été fusionnée. Pouvez-vous faire un git pull des derniers changements et reconstruire votre conteneur quand vous aurez un moment ?
La mise à niveau et la nouvelle tentative du travail ont réussi à envoyer l’e-mail ; j’ai vérifié les journaux d’e-mails et il a été signalé comme envoyé.
