أقوم بتشغيل تثبيت Discourse صغير نسبيًا منذ سنوات. إنه ذو حركة مرور منخفضة إلى حد ما، لذلك استغرق الأمر بعض الوقت لملاحظة أن إرسال رسائل البريد الإلكتروني (الإشعارات، الملخصات) قد فشل بوضوح منذ بضعة أشهر. تشير التحقيقات إلى الترقية إلى 2.8.0.beta7 حوالي 2022-10-22، سابقًا كنا على 2.8.0.beta4. على الأقل لم أتلق أي بريد إلكتروني من هذا التثبيت حول المشاركات أو الرسائل.
تتكدس رسائل البريد الإلكتروني في Sidekiq، مع رسالة لا يمكنني ربطها، ولا أجد أي شيء مناسب عند البحث عنها - كانت هناك تقارير عن رسائل undefined method، ولكن لا تتطابق أي من الشروط مع حالتي. (إنه ليس TLS، ولا يوجد مهلة لخادم البريد، ولا توجد إضافة الأحداث، ويجب أن يكون إصلاح الوسائط الآمنة قد تم بالفعل - بالإضافة إلى ذلك، كانت رسائل الخطأ الدقيقة مختلفة.)
خطأ في Sidekiq:
Wrapped NoMethodError: undefined method `value' for #<Array:0x00007f7fd5277d68> Did you mean? values_at
الجزء الذي يلي #<Array: مختلف لكل بريد إلكتروني محتفظ به. قمت بإعادة تثبيت Discourse إلى جهاز افتراضي جديد الليلة الماضية واستعدت من نسخة احتياطية حديثة - ولكن يبدو أن مشكلة البريد الإلكتروني قد تم استعادتها مع البيانات
نظرًا لأن معدل الخطأ بدأ في الارتفاع في أواخر أكتوبر، فأنا متأكد تمامًا من أن هذا تم تقديمه بواسطة 2.8.0.beta7:
## يتم وضع المكونات الإضافية هنا
## انظر https://meta.discourse.org/t/19157 للتفاصيل
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## أي أوامر مخصصة للتنفيذ بعد البناء
هل هذا تثبيت قياسي؟ إذا كان لديك حاوية بيانات منفصلة، فهل أعيد بناؤها؟ هل تم تحديث PostgreSQL؟ (على الرغم من أنني أعتقد أنه لا يزال هناك تحقق من هذا في الكود)
نعم، إنها تثبيت قياسي؛ على حد علمي، هناك حاوية واحدة فقط قيد التشغيل. (قم بتشغيل جهاز افتراضي جديد، وأعد توجيه نظام أسماء النطاقات، وقم بتحديث apt، وقم بترقية apt، وأعد التشغيل، وقم بسحب git، وقم بتشغيل ./discourse-setup، وقم بإعداد الواجهة المستندة إلى الويب، وقم بتحميل النسخ الاحتياطي، واستعادة النسخ الاحتياطي، وأعد تمكين البريد، وشاهد الأخطاء مرة أخرى.) لاحظ أن التثبيت القديم كان قادرًا على إرسال رابط النسخ الاحتياطي عبر البريد الإلكتروني، ولا يزال إرسال رسائل البريد الإلكتروني التجريبية يعمل في التثبيت الجديد — يبدو أن رسائل البريد الإلكتروني المتعلقة بالنشر فقط هي التي تفشل.
root@discourse:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ac408a70305d local_discourse/app \"/sbin/boot\" 12 hours ago Up 12 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
تعديل:
root@discourse:~# apt update
Hit:1 https://download.docker.com/linux/debian buster InRelease
Hit:2 http://deb.debian.org/debian buster InRelease
Get:3 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Get:4 http://security.debian.org/debian-security buster/updates InRelease [65.4 kB]
Fetched 117 kB in 2s (60.5 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
في الواقع، فشلت عمليات الاستعادة الأولى. فشل database_restorer.rb في restore_dump بسبب روابط مكررة في post_id 3841. انتهى بي الأمر باستبدال هذه الروابط في منشور من عام 2017 لقطة شاشة لها من التثبيت القديم وقمت بعمل نسخة احتياطية أخرى؛ فقط بعد ذلك تمكنت من استعادة النسخة الاحتياطية على التثبيت الجديد. بما أنك ذكرت postgres، فقد حدث هذا أثناء CREATE INDEX مع ERROR: could not create unique index \"unique_post_links\". مزيد من المعلومات: EXCEPTION: psql failed: DETAIL: Key (topic_id, post_id, url)=(1300, 3841, [redacted]) is duplicated.
بينما لا أعتقد أن هذا مرتبط بشكل مباشر، فقد اعتقدت أنه يجب علي ذكره.
إذن، إذا لم يعرف أحد طريقة سهلة لإصلاح ذلك، فلنقم بتصحيح الأخطاء بشكل صحيح. لكنني بحاجة إلى مساعدتكم، حيث أن Discourse تطبيق معقد إلى حد ما يستخدم مجموعة من التقنيات التي لست على دراية بها. إذن: كيف يتم إرسال رسائل البريد الإلكتروني إلى Sidekiq؟
ما هو المكون في Discourse الذي يعطي Sitekiq طريقة “value”؟
مع توقف إشعارات البريد الإلكتروني عن العمل بعد الترقية، فإن Discourse عديم الفائدة للأسف الآن. بدلاً من الاهتمام الفوري، تستغرق المواضيع الآن أيامًا للحصول على الاهتمام، إن وجدت، حيث لا يقوم الأشخاص بالاستطلاع النشط في عام 2022. لا يوجد إشعار ⇒ لم يحدث شيء ⇒ لا حاجة للتحقق من الموقع
يبدو هذا كفهرس تالف. لا أعتقد أنني رأيت هذا على postgres 13. يبدو أنك قمت بإصلاح تلك الموجودة في موقع قديم ثم قمت بالترقية عن طريق النسخ الاحتياطي والاستعادة إلى موقع جديد؟
يبدو أن المشكلة تتعلق بشيء في الكود الذي يرسل الإشعارات، ولكنه مشكلة في sidekiq.
كما قلت، الموقع القديم يعمل، وقمت بعمل نسخة احتياطية ووضعتها على تثبيت جديد، فشلت الاستعادة. قمت بتعديل المنشور المشار إليه على أنه المذنب حتى نجحت الاستعادة على التثبيت الجديد. فقط لأرى أن لدي المشكلة مع Sitekiq مرة أخرى/لا تزال.
الموقع القديم يعمل بنظام postgres 13 أيضًا (ولكنه يعود لعدة سنوات، لذا من المحتمل جدًا أنه لم يبدأ بهذا الإصدار )
جربت مع مستخدم جديد، يحصل على بريد التسجيل الخاص به بشكل صحيح. ولكن الإشعارات حول الردود على منشوراته، لا؛ Sidekiq يخرج بخطأ.
إذًا، بالنسبة لي هذا يعني أن Discourse يعطي بعض المعلومات الخاطئة لـ Sidekiq عندما يوجهه لإرسال الإشعارات (على عكس بريد التسجيل). كيف يمكنني تصحيح المزيد من الأخطاء؟
حسنًا، إذا تم إصلاح الفهارس، فهذا يشير لي إلى أن شيئًا ما يتم استدعاؤه بمصفوفة بدلاً من نموذج يحتوي على value. المشكلة ليست مع sidekiq، بحد ذاتها، ولكن مع الوظيفة التي يتسبب sidekiq في استدعائها.
لذا يبدو أن شيئًا ما يتم استدعاؤه ويعيد مصفوفة بدلاً من عنصر واحد، ولكن لا يمكنني تخمين ما هو. أعتقد أنك ستحتاج إلى النظر في /var/discourse/shared/standalone/logs/rails/production.log (أو شيء مشابه جدًا لذلك إذا كانت أصابعي أو ذاكرتي تخونني). ثم يمكنك البحث في تلك السجلات عن هذا الخطأ (أو التسبب في حدوثه مرة أخرى حتى يكون في نهاية الملف). يجب أن تحصل على مزيد من المعلومات حول ما يفشل هناك.
بدأ POST "/sidekiq/retries" لـ 185.39.142.187 في 2022-04-11 16:31:35 +0000
البدء
بدأ GET "/sidekiq/retries" لـ 185.39.142.187 في 2022-04-11 16:31:35 +0000
تم عرض email/notification.html.erb (المدة: 42.8 مللي ثانية | التخصيصات: 4323)
تم عرض layouts/email_template.html.erb (المدة: 0.3 مللي ثانية | التخصيصات: 29)
استثناء المهمة: طريقة غير معرفة `value` لـ #<Array:0x00007ff393af6c78>
هل قصدت؟ values_at
فشل
هو – في كود Discourse؟ – المكان الذي يتعثر فيه Sidekiq؟
يتم استدعاء هذا من…
228 MessageBuilder.custom_headers(SiteSetting.email_custom_headers).each do |key, _|
*229 value = header_value(key)
230
231 # Remove Auto-Submitted header for group private message emails, it does
232 # not make sense there and may hurt deliverability.
إذًا يمكن أن يكون رأسًا مخصصًا؟
بالفعل لدي إدخال هناك:
لقد أعدت تعيين هذا إلى الإعدادات الافتراضية، و… في الواقع يبدو أن إشعارات البريد الإلكتروني يتم إرسالها مرة أخرى، كما تحقق القراء.
شكرًا!
يبقى سؤال واحد، مع ذلك: لماذا يتسبب »Auto-Submitted: auto-generated|Precedence: bulk« في هذا الفشل؟ يذكر أن الرؤوس المخصصة يجب فصلها بـ »|«.
وفقًا لـ RFC، يمكن أن تظهر العديد من الحقول أكثر من مرة، وسنعيد سلسلة نصية للقيمة إذا كان هناك رأس واحد فقط، أو إذا كان هناك أكثر من رأس مطابق، فسنعيد مصفوفة من القيم بالترتيب الذي تظهر به في الرأس مرتبة من الأعلى إلى الأسفل.
يقوم ديسكورس بتعيين رأس Precedence تلقائيًا، لذلك نظرًا لأنك تضيف واحدًا أيضًا عبر إعداد email_custom_headers، فهناك الآن رأسانPrecedence، ويعيد @message.header["Precedence"] مصفوفة بدلاً من سلسلة نصية.
أعتقد أن هذه المشكلة سيتم تفعيلها في أي وقت يحتوي فيه email_custom_headers على رأس موجود بالفعل في كائن الرسالة.
يبدو لي هذا ما يحدث (اقترحت أن شيئًا ما كان مصفوفة بدلاً من عنصر واحد، لكن لم أستطع تخيل كيف يمكن أن يكون ذلك صحيحًا) وهو خطأ.\n\nسأقوم بتغيير عنوان هذا الموضوع وفئته.
)
