في صباح الخميس الجميل هذا، أطرح أمامكم لغزًا مثيرًا للاهتمام. ألاحظ ما يبدو أنه عداد غير مقروء إيجابي كاذب على موقعي.
ما الذي يحدث
تظهر شريط التنقل العلوي غير مقروء (14). ولكن عند النقر عليه والانتقال إلى /unread، لا توجد مواضيع غير مقروءة مدرجة. تقول الصفحة إنه لا يوجد شيء غير مقروء متبقي.
يواجه مستخدمون آخرون غير موظفين نفس المشكلة أيضًا، وإن كان ذلك مع أعداد غير مقروءة مختلفة.
في تطبيق Discourse على iOS، أرى أيضًا عددًا غير مقروء عندما لا توجد مواضيع غير مقروءة، مرة أخرى مع أرقام مختلفة أحيانًا.
لا تزال المشكلة تحدث هناك، لذا لا يبدو أنها ناتجة عن سمات أو تخصيصات إضافية من طرف العميل. لا توجد «همسات» في أي موضوع، لذا من المرجح أنها ليست ذلك أيضًا.
كما لا يمكنني استخدام تجاهل، لأنه لا يوجد زر تجاهل على /unread عندما تكون قائمة غير المقروءة فارغة.
السلوك المتوقع
إذا قال شريط التنقل غير مقروء (14)، فيجب أن أرى 14 موضوعًا غير مقروء على /unread، أو على الأقل بعض المواضيع غير المقروءة المرئية.
السلوك الفعلي
يقول شريط التنقل غير مقروء (14)
/unread فارغ
لا يتوفر زر تجاهل
تستمر المشكلة في الوضع الآمن
أسئلة
هل توجد طريقة معروفة لإعادة بناء/إعادة تعيين حالة غير المقروء لمستخدم واحد؟
هل توجد عدم اتساق على جانب الخادم يمكن أن يتسبب في استمرار أعداد غير المقروء حتى عندما تكون /unread فارغة؟
سابقًا، سألت الذكاء الاصطناعي على ask.discourse.org عن هذه المشكلة، وفي النهاية نصحتني بنشر تقرير خطأ هنا.
آه، مشكلة الرسائل غير المقروءة الوهمية قد أصابت موقعك!
هل قمت بتغيير أي أذونات للأقسام مؤخرًا أو نقلت بعض المواضيع إلى قسم آمن؟ يبدو أن شيئًا ما قد غيّر حالة التتبع.
أليس من الأفضل إعادة تعيينها لجميع المستخدمين إذا كان آخرون يعانون من نفس المشكلة؟
أعتقد أنه يمكن إصلاح هذا الأمر للجميع عبر وحدة تحكم Rails، لكنه أمر معقد بعض الشيء، وأحتاج إلى فهمه واختباره أولًا. أنا حاليًا على الهاتف المحمول، لكنني سأحاول نشر حل خلال قليل إذا لم يفعل شخص آخر ذلك.
نعم. عمل موظفونا بشكل خاص على قسم مشابه لـ #documentation، وأصبح علنيًا مؤخرًا بعد اكتماله.
نعم، بالتأكيد. كانت فكرتي هي تجربته على نفسي أولاً، ثم إصلاحه للجميع. نظرًا لأن هذه خلل معقد الاختبار (على الأقل بالنسبة لي)، لم أكن أريد إثارة آمال الجميع حتى يكون هناك حل يعمل.
شكرًا لك على الثقة. لاحظت هذا الصباح إصدار مايو 2026 الشهري May 2026 monthly releasev2026.05، وظننت أنه قد يحل المشكلة، لكنها لا تزال قائمة. أنا متأكد من أن الفريق يعمل على ذلك. ديسكورد رائع.
أوه، يا إلهي. بصراحة، لقد مررت بقراءة جميع تقارير الأخطاء ذات الصلة bug. للحظة، حتى فكرت في إخفاء علامة التبويب “غير المقروء” من التنقل، وتجاهلها ببساطة. لكن هذا لن يحل أي شيء، أليس كذلك؟ يبدو أنها حتى تلاحقني هنا في ميتا.
حسناً، سيعمل هذا السكربت الخاص بـ Rails كوظيفة عالمية لـ “تحديد الكل كمقروء”، مما يجبر عداد “غير المقروء” على العودة إلى 0 لجميع المستخدمين، لذا للأسف سيؤدي ذلك إلى مسح أي عدادات غير مقروءة حقيقية بالإضافة إلى أي عدادات غير مقروءة وهمية. يمكننا تنفيذ ذلك عبر أمر SQL داخل Rails. ولكن تجدر الإشارة إلى أن هذا لا يحل الخلل الجذري. أيضاً، فكرة جيدة أن يكون لديك نسخة احتياطية حديثة في متناول اليد، لكنني جربت هذا على منتدى التطوير الخاص بي وقد نجح.
cd /var/discourse ./launcher enter app rails c
انسخ الكتلة التالية بالكامل واضغط على Enter
sql = <<~SQL
UPDATE topic_users
SET last_read_post_number = topics.highest_post_number
FROM topics
WHERE topics.id = topic_users.topic_id
AND COALESCE(topic_users.last_read_post_number, 0) < topics.highest_post_number
AND topic_users.notification_level IN (2, 3, 4) -- Tracking, Watching, Watching First Post
SQL
# تشغيل التحديث
result = ActiveRecord::Base.connection.execute(sql)
puts "تم مسح #{result.cmd_tuples} مواضيع غير مقروءة بنجاح على مستوى الموقع."
# إجبار متصفحات العملاء على إسقاط حالتها المخزنة ومزامنتها مع قاعدة البيانات
MessageBus.publish("/topic-tracking-state", { clear: true })
قد يحتاج المستخدمون إلى تحديث الصفحة قسرياً (hard refresh) لرؤية حالة «غير المقروء» الممسوحة.
بصراحة، لقد مررت بقراءة جميع تقارير الأخطاء ذات الصلة 
تم حل المشكلة.
أتمنى لك يومًا سعيدًا!