واجهت مشكلة متقطعة حيث يُحفظ المنشور المُعدَّل بنجاح، لكن المنشور المُعرض مسبقًا في DiscourseHub على iOS يبقى قديمًا أحيانًا حتى أُحدِّث الموضوع.
بيئة العمل
الموقع الإنتاجي هو نسخة Discourse مُستضافة ذاتيًا تخصني، أستخدمها بشكل خاص كملف مرجعي شخصي.
عند إعادة إنتاج المشكلة اليوم:
- العميل: DiscourseHub على iPhone
- iOS: 27.0.1
- Discourse الإنتاجي:
v2026.10.0-latest +112 - الموقع: مُستضاف ذاتيًا، ملف مرجعي خاص
- متصفح iOS الافتراضي: iCab Mobile
غيّرت متصفحي الافتراضي إلى iCab Mobile بسبب مشكلة محلية غير مرتبطة بتنزيل الملفات. ومع ذلك، حدثت إعادة الإنتاج هذه أثناء استخدامي لموقع Discourse داخل DiscourseHub، وليس بعد فتح متصفح خارجي، لذا لا أعتقد حاليًا أن اختيار المتصفح الافتراضي ذو صلة.
سير العمل الواقعي
تضمن الموضوع الذي لاحظت فيه المشكلة حوالي 50 منشورًا تمثل شرائح محاضرات.
سير عملي المعتاد هو:
- إنشاء منشور يحتوي على صورة شريحة محاضرة؛
- لاحقًا، العمل على الموضوع بشكل متتالٍ؛
- تعديل كل منشور موجود؛
- إضافة نص OCR / ملاحظات أسفل صورة الشريحة المنشورة بالفعل؛
- الضغط على حفظ التعديل والانتقال إلى الشريحة التالية.
لذا، هذه ليست تعديلات سريعة اصطناعية؛ بل هو سير عمل دراسي طبيعي أضيف فيه نصوص OCR تدريجيًا إلى منشورات صور شرائح المحاضرات.
بالنسبة للمنشورات الأولى في الموضوع، استبدل الضغط على حفظ التعديل المنشور المعروض بمحتوى التعديل الجديد فورًا، كما هو متوقع.
لاحقًا في نفس الموضوع، واجهت حالات حيث:
- عدّلت المنشور وأضفت نص OCR.
- ضغطت على حفظ التعديل.
- تم حفظ التعديل بنجاح.
- بقي المنشور المعروض في DiscourseHub على محتواه السابق.
- أظهر تحديث الصفحة التعديل المحفوظ بالفعل فورًا.
لذا، يبدو أن التعديل نفسه نجح. الجزء القديم يبدو أنه تمثيل العميل المُحمَّل مسبقًا للمنشور.
اختبار التطوير
ثم أنشأت نسخة تطوير نظيفة تمامًا من فرع main الحالي في upstream:
833e1576d47 DEV: Update README.md note on self-hosting (#44320)
أنشأت موضوعًا يحتوي على 60 منشورًا، مع صورة في كل منشور، لمحاكاة بنية الموضوع الإنتاجي.
ثم كررت سير العمل في Firefox على Linux، حيث عدّلت النصوص في منشورات الصور الموجودة مسبقًا.
لاحظت في البداية تحديثًا قديمًا محتملاً حول المنشور 19 في اختباري الأول. ومع ذلك، بعد تكرار التجربة بحذر أكبر - بما في ذلك إنشاء موضوع جديد من 60 منشورًا وتعديل المنشورات بشكل متتالٍ - لم أتمكن من إعادة إنتاج سلوك الإنتاج في Firefox/Linux على الفرع الرئيسي الحالي.
كانت التعديلات هناك تعيد رسم المنشور فورًا بعد حفظ التعديل، بما في ذلك ما يتجاوز بكثير المجموعة الأولى من المنشورات في الموضوع.
هذا جعلني أقل ثقة في أن ترقيم صفحات الموضوع أو مجموعة تدفق 20 منشورًا المعتادة هي السبب بنفسها.
الاختبار التالي
كانت إعادة الإنتاج في الإنتاج داخل DiscourseHub على iOS، وليس PWA على شاشة الرئيسية.
لذلك، المقارنة المقصودة التالية هي:
- نسخة تطوير Discourse الحالية من upstream؛
- نفس موضوع الصور المكون من 60 منشورًا؛
- نفس iPhone الذي يعمل بنظام iOS 27.0.1؛
- DiscourseHub أولًا؛
- Safari على نفس iPhone كمجموعة تحكم؛
- اختيارًا، تطبيق الويب على شاشة الرئيسية كمقارنة أخرى؛
- تعديل المنشورات بشكل متتالٍ باستخدام نفس سير عمل نمط OCR.
حاليًا، حاسوبي المحمول للتطوير متصل بشبكة eduroam، لذا فإن كشف خادم التطوير المحلي الخاص به مباشرةً إلى iPhone ليس أمرًا مباشرًا.
هل تشغيل نسخة التطوير الحالية من الفرع الرئيسي على نفس iPhone في DiscourseHub هو الخطوة الصحيحة التالية لتضييق نطاق المشكلة؟
إذا كان كذلك، فهل هناك طريقة مفضلة يستخدمها فريق Discourse لكشف نسخة تطوير محلية إلى iPhone / DiscourseHub للاختبار، ويفضل عبر HTTPS؟
عند حدوث المشكلة مرة أخرى، يمكنني أيضًا ترك المنشور القديم بدون تحديث وتسجيل شاشة، بحيث يمكن مقارنة حالة الحفظ الناجح/الخادم مباشرةً بما يعرضه عميل DiscourseHub المفتوح بالفعل.
ملاحظة قد تكون ذات صلة
يشبه هذا السلوك، على مستوى عالٍ، مشكلة حالة العميل القديمة التي واجهتها أثناء العمل على
PR #43285, “Refresh event dates in topic lists”.
كانت تلك مسار كود مختلفًا، ولا أقترح أنها نفس الخطأ.
ومع ذلك، كان الفشل المرئي مشابهًا: يمكن أن تكون حالة الخادم صحيحة بينما يستمر عميل مُحمَّل مسبقًا في عرض حالة قديمة حتى يحدث التحديث/إعادة التهيئة ذات الصلة.
في مشكلة تاريخ الأحداث، تمكنت من ملاحظة حالة A/B على عملاء مختلفين مفتوحين مسبقًا اعتمادًا على التوقيت.
هذا يجعلني أتساءل عما إذا كانت مشكلة التعديل هذه موجودة أيضًا في مكان ما في سلسلة الإشعارات / تحديث النموذج / العرض، بدلاً من فشل التعديل نفسه.