رسائل الملخص لا تُرسل للمستخدمين رغم استيفاء جميع الشروط (Discourse 3.6)

نحن نستخدم Discourse 3.6 ونواجه مشكلة حيث لا يتلقى بعض المستخدمين الذين يجب أن يتلقوا رسائل بريد إلكتروني ملخصة أبدًا.

إليك ما أكدناه للمستخدم المتأثر:

  • enable_digest_emails صحيح

  • المستخدم غير نشط لفترة كافية لتشغيل ملخص

  • البريد الإلكتروني صالح ومؤكد

  • لا يوجد رفض أو قمع من مزود البريد

  • رسائل البريد الإلكتروني الأخرى (الإشعارات، إلخ) تُرسل بشكل جيد

  • لا يظهر أي بريد إلكتروني ملخص في سجل المسؤول → رسائل البريد الإلكتروني → المرسلة

  • عند استخدام المسؤول → رسائل البريد الإلكتروني → اختبار الملخص، يُظهر النظام بشكل صحيح “نعم، يجب إرسال ملخص” - ولكن لا شيء يُرسل أو يُسجل فعليًا.

لا تظهر أي أخطاء ذات صلة في سجلات Sidekiq أو الإنتاج.

هل رأى أي شخص آخر فشل رسائل البريد الإلكتروني الملخصة بصمت في الإصدار 3.6 حتى عندما تشير جميع الإعدادات وفحوصات الأهلية في واجهة المسؤول إلى أنه يجب على المستخدم تلقي واحدة؟

إعجابَين (2)

هل قمت بالتحقق من إعدادات المستخدم في علامة تبويب البريد الإلكتروني الخاصة بتفضيلاته؟

نعم، إليك إعداداتهم، وهذا هو عرض الملخص لهم يخبرنا أنه يجب إرساله.

تحديث / خطوات إعادة الإنتاج (Discourse 3.6)

لقد قمت بإعادة إنتاج صريح لهذا باستخدام وحدة تحكم Rails للتأكد مما يحدث على مستوى المهمة. إليك ما نراه للمستخدم المتأثر:

site: hvac

now: 2025-10-15 17:23:01 UTC

disable_emails: “no”

disable_digest_emails: false

default_email_digest_frequency_minutes: 10080

ENV_DISABLE_EMAILS: nil

perform_deliveries: nil

smtp_address: “smtp.netcorecloud.net

smtp_port: 587

– USER –

id: 42122

username: milnerlarry

active: true

suspended: false

email_digests: true

digest_after_minutes: 10080

eligible_by_time: true

– آخر 15 سجل بريد إلكتروني –

2025-10-01 | type=digest | bounced=false

2025-09-22 | type=digest | bounced=false

perform_deliveries_now: true

ثم عندما قمت ببناء الملخص يدويًا، تعتقد Discourse أنها تبنيه ولكنها تُرجع:

mail = UserNotifications.digest(u)

=> Built digest mail: subject=nil bytes=50

لذلك تعتقد Discourse أنها تبني الملخص، ولكنه فارغ في الواقع (subject=nil) - ويتم تخطيه بصمت عند تشغيل المهمة. لا يتم إنشاء أي سجل EmailLog، ولا يتم إرسال أي شيء.

هذا يؤكد:

  • يتم إدراج المهمة بنجاح
  • تم تمكين SMTP والتسليم
  • تنتهي مهمة الملخص بدون خطأ لأن مُرسل البريد يُرجع ملخصًا فارغًا

تشغيل المهمة مباشرة باستخدام:

Jobs::UserEmail.new.execute(“type” => “digest”, “user_id” => u.id”)

ينتج نفس النتيجة - لا يتم إنشاء صف EmailLog جديد.

سبب محتمل:

يبدو أنه يتم تخطي الملخص بسبب شرط “ملخص فارغ” - ربما تغير شيء ما في كيفية تقييم Discourse 3.6 للمحتوى لتضمينه. يعرض عرض Admin → Emails → Digest Test الملخص بشكل صحيح، ولكن المهمة الخلفية لا ترى شيئًا لتضمينه.

ملخص:

:white_check_mark: مستخدم مؤهل

:white_check_mark: بريد إلكتروني نشط + SMTP صالح

:white_check_mark: عرض اختبار الملخص في الإدارة بشكل صحيح

:prohibited: تتخطى مهمة الملخص الخلفية بصمت (ملخص فارغ)

:prohibited: لم يتم تسجيل أي EmailLog أو محاولة إرسال

أود تأكيدًا من الفريق - هل هناك احتمال وجود تراجع في كيفية جمع UserNotifications.digest للمحتوى في 3.6؟

نقوم ببعض العمل الإضافي هنا، ووجدنا عددًا قليلاً (من أصل 4 آلاف) من المستخدمين الذين يحصلون بالفعل على ملخصات النشاط بشكل موثوق.

مقارنة أحد هؤلاء المستخدمين الذين يحصلون على الملخصات بآخر لا يحصل عليها لا تُظهر أي اختلاف في إعداداتهم.

===== xxxxx (المعرف: 4149) =====
نشط: صحيح، معلق: خطأ، صامت: خطأ
البريد الإلكتروني مؤكد: خطأ
ملخص ممكّن: صحيح
تكرار الملخص: 10080 دقيقة
آخر ظهور: 2025-03-24 20:58:55 UTC
آخر بريد إلكتروني: 2025-10-16 17:07:53 UTC
الفئات المكتومة:
محاولة ملخص إحصائيات المستخدم: 2025-10-16 17:07:53 UTC
إجمالي رسائل البريد الإلكتروني المرسلة: 16
===== xxxxxxx (المعرف: 42206) =====
نشط: صحيح، معلق: خطأ، صامت: خطأ
البريد الإلكتروني مؤكد: خطأ
ملخص ممكّن: صحيح
تكرار الملخص: 10080 دقيقة
آخر ظهور: 2025-09-14 15:52:54 UTC
آخر بريد إلكتروني: 2025-10-01 23:30:33 UTC
الفئات المكتومة:
محاولة ملخص إحصائيات المستخدم: 2025-10-16 17:32:34 UTC
إجمالي رسائل البريد الإلكتروني المرسلة: 2

بالتأكيد هناك إعدادات أخرى ولكنني اعتقدت أن هذه مقارنة مثيرة للاهتمام على أي حال.

هل يمكن لأي شخص تقديم أمر Rails يمكننا تشغيله للتحقق من عدد الملخصات / الملخصات النشطة المتأخرة حقًا؟ في الأساس فحص صحي للتأكد من أن النظام يرسل الملخصات كما هو مصمم.

يمكنك تجربة استعلام وحدة تحكم Rails أدناه، للمستخدمين النشطين الذين لديهم ملخصات البريد الإلكتروني ممكّنة ويحين موعد إرسال بريدهم الإلكتروني الملخص التالي لهم

User.joins(:user_option)
  .where("user_options.email_digests = ?", true)
  .where("users.suspended_at IS NULL")
  .where("COALESCE(users.last_emailed_at, users.created_at) < (NOW() - INTERVAL '1 minute' * user_options.digest_after_minutes)")
  .count

هل من الممكن تخطي الملخص لأن المستخدم لم يزر لـ Suppress digest email after days؟

@jahan_gagan هذا مفيد، ولكنه سيخبرنا بمن سيحصل على ملخص موجز/نشاط، ولكن ليس بمن لم يحصل على ملخص نشاطه. هل هذا منطقي؟ السؤال هو كيف نرى من لا يحصل على الملخص الذي ينبغي أن يحصل عليه.

@Moin لدينا الإعداد على 0 - لا ينبغي أن يكون هذا عاملاً.

هل أنت متأكد من أن 0 يعطل ذلك؟ هل جربت رقمًا كبيرًا بدلاً من ذلك؟

@Moin شكراً، لقد قمت بتغييره إلى 3000 - لم يتغير شيء في الملخص المرسل. لا يزال هناك مئات يتم إرسالها بتردد أسبوعي (الآن لأكثر من أسبوعين) دون إرسالها.

حسنًا ، إليك اختبار لمعرفة من هو مؤهل حاليًا:

سنقوم بفرض الإرسال الآن ، ولم يتم إرسال أي شيء …

نأخذ عينة مستخدم لا يتلقى الملخص ، ونتحقق من واجهة المسؤول ، ويبدو أنهم مؤهلون بالكامل …

حسنًا، بسبب عدم وجود أفكار أخرى، قمنا بتغيير وقت تكرار الملخصات إلى يومي لجميع المستخدمين عبر المسؤول، إلى 1440.
وفجأة تم إرسال جميع الملخصات…
هل لدى أي شخص أي فكرة عن سبب ذلك؟ كان يجب أن يكون لتغيير التكرار أي تأثير نظرًا لأنه يمكننا رؤية هؤلاء المستخدمين كانوا مؤهلين بالتكرار الأسبوعي.

تحدثت مبكرًا جدًا، لقد نجح تغيير التردد لمجموعة واحدة من المستخدمين (موقع واحد) ولكنه لم يفعل شيئًا لمجموعة أخرى. يستمر اللغز…

أعتقد أنه قد يكون بسبب أحد المتطلبات الأخيرة في الاستعلام الذي ربطته أعلاه.

بعد التحقق من أن المستخدم حقيقي، ونشط، وليس في مرحلة الإعداد، وليس معلقًا، والتحقق من أنه لم يقم بتعطيل الملخصات وأن التردد أكبر من 0، وهناك بريد إلكتروني أساسي ودرجة الارتداد جيدة، هناك بعض الفحوصات المستندة إلى الوقت:

آخر ظهور كان قبل أكثر من digest_after_minutes
آخر ظهور في غضون suppress_digest_email_after_days
آخر فحص إذا كان يجب على المستخدم تلقي ملخص كان قبل digest_after_minutes.

أعتقد أن الأخير قد يكون السبب. إذا حاول Discourse إرسال الملخص بالأمس وكان digest_after_minutes أسبوعًا، فلن يحاول مرة أخرى حتى يمر أسبوع. إذا قللت ذلك، يحدث المحاولة التالية قريبًا.

إعجاب واحد (1)

@Jacob_Peebles يبدو أنك كنت تعاني من هذا لفترة طويلة! أعتقد أن Digest Emails Not Sending to All Users – Need Help Debugging في مارس كان حول نفس المشكلة، هل أنا على حق؟

هل ساعدت أحدث مشاركة لموين؟ إذا كان الأمر كذلك، فأخبرنا حتى نتمكن من إنهاء هذا الموضوع.