साइटच्या प्रकाशन प्लॅटफॉर्मवर चालवल्या गेलेल्या एका क्लीनअप स्क्रिप्टने चुकून कोड स्निपेट्सना चुकीच्या स्वरूपातील Liquid व्हेरिएबल्स समजून घेतले आणि ज्या लेखांमध्ये ते होते त्या प्रत्येक लेखातून ते काढून टाकले. या त्रुटीमुळे डझनान्न तांत्रिक पोस्टमधील वाचकांना आवश्यक असलेले उदाहरण कोड उपलब्ध राहिला नाही, ज्यामुळे तातडीने रोलबॅक करणे आणि कंटेंट मायग्रेशन कसे तपासावे यावर पुनर्विचार करणे आवश्यक झाले.
ही त्रुटी कशी घडली
हा प्लॅटफॉर्म Liquid वापरतो, जी एक टेम्प्लेटिंग भाषा आहे आणि ती {{ … }} सारख्या टॅग्सचा वापर करून डायनॅमिक कंटेंट मार्क करते. रेंडरिंगमध्ये अडथळा आणू शकणारे विस्कळीत टॅग्स काढून टाकण्यासाठी एक नियमित देखभाल कार्य (maintenance job) राबवले जाणार होते. स्क्रिप्टच्या पार्सरने असे ओपनिंग टॅग्स शोधले ज्यांना मॅचिंग क्लोजिंग टॅग नव्हता आणि जेव्हा त्याला असे टॅग सापडले, तेव्हा त्रुटी "सुधारण्यासाठी" त्याने संपूर्ण ब्लॉकच डिलीट केला.
प्रत्यक्षात, पार्सर {% raw %} आणि {% endraw %} हे कोड ब्लॉक्स वेढणारे टॅग्स ओळखण्यात अपयशी ठरला. हे टॅग्स Liquid ला सांगतात की आतला सर्व मजकूर 'लिटरल टेक्स्ट' म्हणून घ्यावा, परंतु दोषपूर्ण स्क्रिप्टने ओपनिंग {% raw %} ला एक अपूर्ण व्हेरिएबल ({{% raw %}) मानले आणि त्याभोवतीचा कोड काढून टाकला. लॉग झालेला एरर मेसेज असा होता:
Liquid syntax error: Variable '{{% raw %}' was not properly terminated.
ही स्क्रिप्ट लाईव्ह कंटेंट रिपॉझिटरीवर चालवली गेल्यामुळे, ही प्रक्रिया मोठ्या प्रमाणावर झाली आणि एकाच वेळी सर्व बाधित लेखांमधील कोड उदाहरणे पुसून टाकली गेली.
काय धोक्यात आहे
तांत्रिक लेख संकल्पना स्पष्ट करण्यासाठी, निकाल पुन्हा मिळवण्यासाठी आणि वाचकांना टप्प्याटप्प्याने प्रक्रिया समजून सांगण्यासाठी कोड स्निपेट्सवर अवलंबून असतात. हे ब्लॉक्स गमावल्यामुळे पोस्ट मोठ्या प्रमाणात निरुपयोगी ठरतात, लेखकांना मजकूर पुन्हा लिहावा लागतो आणि प्लॅटफॉर्मच्या विश्वासार्हतेवर प्रश्नचिन्ह निर्माण होते. ज्या साइटची प्रतिष्ठा उच्च-गुणवत्तेच्या डेव्हलपर डॉक्युमेंटेशनवर अवलंबून असते, अशा साइटसाठी ही घटना वाचकसंख्या आणि योगदानकर्त्यांचा विश्वास या दोन्हीसाठी धोकादायक आहे.
बहुतेक वाचकांकडून सुटलेले तपशील
- सँडबॉक्सिंगशिवाय बॅच प्रोसेसिंग – स्क्रिप्ट स्टेजिंग कॉपीऐवजी थेट प्रोडक्शन डेटावर चालवण्यात आली होती.
- अपुरे टॅग हँडलिंग – केवळ काही ठराविक Liquid टॅग्सचा विचार करण्यात आला होता;
{% raw %}ला व्हाईटलिस्टमधून वगळण्यात आले होते. - इन्क्रिमेंटल टेस्टिंगचा अभाव – लहान नमुन्यावर पायलट रन न करता हे कार्य संपूर्ण डेटासेटवर लागू करण्यात आले.
काय रोखता आले असते
- कॉपीवर मायग्रेशन चालवा – कोणतेही बल्क ट्रान्सफॉर्मेशन प्रथम डेटाबेसच्या सँडबॉक्स आवृत्तीवर लागू करा.
- सर्व टॅग व्हेरिएशन्ससाठी पार्सरचे युनिट-टेस्ट करा – यामध्ये raw ब्लॉक्स, कमेंट टॅग्स आणि नेस्टेड स्ट्रक्चर्स सारख्या एज केसेसचा समावेश करा.
- हळूहळू रोलआउट करा – मर्यादित संख्येने लेख प्रोसेस करा, निकालांची पडताळणी करा आणि त्यानंतरच व्याप्ती वाढवा.
प्रतिवाद
काही लोकांचा असा युक्तिवाद आहे की वेगाने चालणाऱ्या साइट्ससाठी प्रत्येक स्क्रिप्ट पूर्ण बॅकअपवर तपासणे अव्यवहारिक आहे आणि डेटा गमावण्याचा धोका वेगाने उपाय करण्याच्या गरजेपेक्षा कमी आहे. वेग महत्त्वाचा असला तरी, मोठ्या प्रमाणावर झालेली डिलीशनची प्रक्रिया उलट करण्याचा खर्च – डेव्हलपरचा वेळ आणि प्रतिष्ठेला होणारी इजा या दोन्ही दृष्टीने – सावधगिरीने केलेल्या रोलआउटमुळे होणाऱ्या विलंबापेक्षा जास्त असतो.
पुढे काय पाहायचे
टीमने बॅकअपमधून हरवलेला कोड पुनर्स्थापित केला आहे आणि सर्व Liquid कन्स्ट्रक्ट्स ओळखण्यासाठी क्लीनअप टूलमध्ये सुधारणा करत आहे. ते अपडेटेड टेस्टिंग वर्कफ्लोचा तपशीलवार पोस्ट-मॉर्टम अहवाल प्रकाशित करण्याची आणि सुधारित स्क्रिप्ट सार्वजनिकरित्या शेअर करण्याची योजना आखत आहेत, जेणेकरून इतर प्रकाशक अशाच प्रकारच्या चुका टाळू शकतील. ही घटना एक आठवण करून देते: एक छोटीशी पार्सिंग त्रुटी देखील लेखकाचा आठवड्यांचा परिश्रम पुसून टाकू शकते, ज्यामुळे कठोर टेस्टिंग करणे अनिवार्य ठरते.