بالنسبة لرسالة البريد الإلكتروني الأولى للتسجيل، بعد التثبيت باستخدام أحدث صورة Docker، يستجيب خادم SMTP الخاص بي بالرسالة التالية:
Unexpected return code 554 (expected 250):
“Access denied: User `arn:aws:iam::[acct]:user/[user]' is not authorized to perform `ses:SendRawEmail' on resource `arn:aws:ses:us-west-1:[acct]:identity/[identity]'”.
ومع ذلك، يُظهر ملف سجل Discourse production.log ما يلي:
Started PUT "/finish-installation/resend-email" for [ip] at 2020-11-16 20:58:10 +0000
Processing by FinishInstallationController#resend_email as HTML
Parameters: ...
Completed 200 OK in 23ms (Views: 6.4ms | ActiveRecord: 0.0ms | Allocations: 6023)
...
Delivered mail [randid]@[hostname] (191.3ms)
يبدو لي أن الموقع، أو على الأقل السجلات، يجب أن يُرجع خطأً بدلاً من رسالة نجاح.
بشكل عام، تُرسل الرسائل الإلكترونية عبر قائمة انتظار في الخلفية، لذا فإن ذلك غير مرئي للمستخدم.
أنا منفتح على جعل المعالج أكثر أناقة وإبلاغًا صريحًا عن الفشل، لكن سيتطلب ذلك الاستعلام عن الخادم لاكتشاف ذلك. ربما يكون هذا تغييرًا كبيرًا، لست متأكدًا.
بالنسبة للمرشد: لا بأس إذا لم يعرض المرشد حالة الفشل. ومع ذلك، يجب ألا يشير أيضًا إلى أن البريد الإلكتروني تم إرساله بنجاح. ما يقترب أكثر من الحقيقة سيكون أكثر فائدة. إذا كان من الصعب جدًا عرض حالة الإرجاع، فسيكون من الأفضل القول: “تمت إضافة بريد التسجيل بنجاح إلى قائمة الانتظار. راجع /path/to/log لمعرفة الحالة.”
بالنسبة لسجل الأخطاء: يجب على خيط العملية تسجيل الحالة، خاصة عند حدوث خطأ. لست على دراية بالبنية المعمارية، لكنني لا أرى أي شيء مفيد في “unicorn.stderr.log” أو في أي مكان آخر. يجب أن يكون هناك شيء ما يبتلع رمز الإرجاع ورسالة الخطأ…
بعد تسجيل دخول المسؤول، تظهر أخطاء البريد الإلكتروني من وحدة تحكم المسؤول، مما يشير إلى أنها مخزنة في قاعدة البيانات، وكان من الممكن الوصول إليها عبر قاعدة البيانات قبل إكمال أول تسجيل للمسؤول.
تحتوي الجدول skipped_email_logs على المعلومات التي كنت أبحث عنها.
إذا كنت مسجّل الدخول إلى حاوية discourse كمستخدم discourse، فيمكنك تشغيل الأمر التالي:
psql discourse -c "select * from skipped_email_logs"
