حسنًا، لقد قمت بترميز أداة تلوين السجل، وأشعر بالرضا حيال ذلك

…ومن الجدير بالتكرار، أن كل شيء يبدو تمامًا كما أريده أن يبدو ويتصرف تمامًا كما أريده أن يتصرف. وهنا لقطة عمل أخرى!

تم رصد المشكلة

مسلحًا بمُلوِّن السجل الرائع الخاص بي، انتظرت بصبر حتى يعيد سلوك مشكلة منطقة التعليق الخاطئ رأسه الذي لا يزال قبيحًا. لم أضطر إلى الانتظار طويلاً، وفي غضون يومين، حصلت على السبب الجذري. لقد كان هناك طوال الوقت، لو أنني قررت قضاء بعض الوقت في البحث عنه. ها هو:

باختصار: المشكلة هي خطأ أبل. (حسنًا، ليس حقًا. ولكن نوعًا ما.)

باختصار أقل: لقد قمت بإخفاء عنوان IP الخاص بـ Eric، لكنه أخضر داكن، لذا فإن أي مكان في الصورة أعلاه حيث ترى لطخة خضراء داكنة ضبابية، فهذا هو Eric. في ما يقرب من 12 ثانية المعروضة هنا، ترى إريك يضغط على زر “نشر” في توقعاته اليومية – وهذا هو حدث “POST” في أعلى النافذة. الأحداث اللاحقة من عنوان IP الخاص بـ Eric هي أن متصفحه لديه محادثة قياسية بعد النشر مع WordPress حتى يتمكن من عرض إشعار “تم نشر المنشور بنجاح” ثم إعادة رسم محرر كتلة WP.

أسفل منشور إريك، يمكنك رؤية خادم Discourse (بعنوان IP البرتقالي) يُعلم WordPress بأنه أنشأ سلسلة تعليقات Discourse جديدة لمنشور إريك، ثم يلتقط الأشياء التي يحتاجها لعكس منشور إريك كافتتاحية لهذا الموضوع. يمكنك أن ترى أنه يقوم بإجراء GETs للمنشور الفعلي وأيضًا للصور المضمنة في المنشور. بعد حوالي ثانية واحدة من قيام إريك بالضغط على زر “نشر”، يصبح موضوع الخطاب الخاص بالمنشور الجديد جاهزًا، ويتم إرفاقه بمنشور إريك.

آه، ولكن لاحظ ماذا آخر يحدث خلال تلك الثانية الواحدة.

للمساعدة في توسيع نطاق وصول Space City Weather، نقوم بنشر جميع منشورات الموقع بشكل مشترك على Apple News، باستخدام مكون إضافي شائع لـ Apple News (نفس المكون الإضافي الذي يستخدمه Ars، في الواقع). وهنا، مع هذين الطلبين GET مباشرة بعد طلب POST الخاص بـ Eric، تكمن المشكلة: أنت ترى طليعة جيش Apple News الجائع من روبوتات استرجاع القصص، والتي تم استدعاؤها بواسطة حدث “النشر” نفسه، وهي تهاجم وتطالب بنسخة من المنشور الجديد تمامًا قبل الخطاب لديه فرصة للقيام بعمله.