أرى أن الخادم أرسل مجموعة من رسائل البريد الإلكتروني بنجاح حول هذا الموضوع الجديد إلى كل من كان يتابع تلك الفئة، ولا أرى أي أخطاء في سجلات البريد الإلكتروني أو على خادم البريد الإلكتروني.
بالنسبة لهذا الإدخال، نعم، كان لا يزال عالقًا في حلقة إعادة المحاولة حتى يوم أمس، وعندما بعد مئات المحاولات، سئمت منه وقمت بحذفه. آمل ألا أكون قد كسرت شيئًا.
لم أره مرة أخرى، ولكن لم يكن هناك حدث أدى إلى إرسال مئات رسائل البريد الإلكتروني حول منشور واحد. سيكون من الجيد فهم مصدر هذا وماذا يعني.
لقد قمت بالترقية إلى bf987af3ca وأعدت تجربة كل شيء ولا يزال لدي 38 على الأقل من Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RecordInvalid: Validation failed: Post has already been taken تظهر في وحدة تحكم sidekiq الخاصة بي.
بدون المزيد من التحديثات، انخفض العدد الآن إلى 30. أظن أنها تنتهي مهلتها، باستثناء أن حساب الاختبار الخاص بي تلقى النشرة الأسبوعية (المتأخرة)، وأفترض أن هذا مرتبط. لست متأكدًا من مكان البحث في السجلات لمعرفة ما إذا كان أي منها يتخلى عن المحاولة بالفعل.
يبدو أنها تفشل في الغالب ولكنها تنجح أحيانًا، وهذا بالتأكيد يشير إلى حالة سباق في مكان ما.
تبدو تتبعات المكدس الخاصة بي كما رأى @RBoy و @md-misko، ولكن إليك تتبع المكدس الكامل، وليس فقط المقتطع من زر “نسخ”:
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'
هل هناك أي معلومات أخرى يمكنني تقديمها للمساعدة في تصحيح هذا؟
4 إعجابات
RGJ
(Richard - Communiteq)
قسَّم هذا الموضوع في
16
اكتشفت أن خادم البريد الخاص بي كان يستخدم شهادة لخادم آخر في التوازن الدائري الخاص به، وأملت أن يكون عدم تطابق اسم المضيف هو المشكلة. قمت بالتحديث إلى b850c12793 أثناء عملية التغيير إلى خادم لم يكن به عدم تطابق في الشهادة، لكن ذلك لم يحل المشكلة. أعدت محاولة بعض المهام، لكن لم تكتمل أي منها بنجاح. لذلك، هذه المشكلة ليست عرضًا لعدم تطابق الشهادات المخفية.
تم بناء هذا باستخدام discourse_docker 2a9faf7e5680b9.
تحديث discourse_docker إلى 241a42ce718، ومعها discourse إلى 95e7e10417، لم يحل المشكلة أيضًا. لا يزال لدي 30 فشلًا من هذا النوع يتم إعادة محاولتها.
بناءً على ما تصفه وبالنظر إلى هذا المنشور، قد تكون هناك مشكلات متعددة هنا:
قد لا يقوم الخادم بتقييد محاولات إعادة إرسال البريد الإلكتروني مما يتسبب في انتهائه أو رفضه من قبل خادم البريد. ولكن هناك مشكلة أساسية أخرى إذا كانت شهاداتك وتكوينك صالحين ولا يزال البريد الإلكتروني لا يتم إرساله. بالنسبة للبعض، يبدو أنه يستهلك مساحة القرص أيضًا. لقد تحققت من جهازي ولكنني لم ألاحظ ذلك هنا.
لم تنفد المساحة لدي، ويحدث هذا حتى عندما أختار وظيفة واحدة بالضبط لإعادة تشغيلها، لذا لا يبدو أنه حالة تسابق. من الواضح أن هناك أكثر من مشكلة واحدة هنا، وما أراه هنا لا يتعلق بالموضوع المرتبط.
(اتضح أنني لم أواجه مشكلة في الشهادة بعد كل شيء؛ كانت أسماء الخوادم في اسم الخادم البديل. لكنني انتقلت إلى استخدام اسم المضيف الذي يتطابق مع SN على أي حال، ولم يحدث فرقًا.)
أنا أرسل عددًا هائلاً من رسائل البريد الإلكتروني بنجاح، وهذه الوظائف القليلة عالقة فقط. لا أعرف، على سبيل المثال، ما هي إدخالات السجل التي يجب البحث عنها للمساعدة في التشخيص.
لقد راجعت رسائل البريد الإلكتروني الفاشلة البالغ عددها 29 للتأكد من عدم وجود أي شيء مهم لإرساله، وعلى حد علمي، لم يكن هناك شيء، لذا قمت بحذف جميع المهام في sidekiq، في حال كان ذلك بسبب مشكلة عابرة ناتجة عن مهام البريد الإلكتروني التي تمتد عبر الترقيات. ومع ذلك، دون تطبيق المزيد من التحديثات، لدي الآن حالة أخرى واحدة من نفس الفشل.
أشارك هذا فقط كمعلومة بأنه مشكلة مستمرة وليست مشكلة عابرة غريبة.
