वह जाँच जो हमेशा सही निकलती है

इस सेवा में 23 UPDATE स्टेटमेंट हैं। उनमें से ठीक एक जाँचता है कि उसने कुछ बदला या नहीं। वह जाँच यह है:

'success' => $n->rowCount() >= 0

rowCount() तब 0 लौटाता है जब कोई पंक्ति मेल नहीं खाती। शून्य, शून्य से बड़ा या उसके बराबर है। जाँच हर हाल में पास हो जाती है।

यह स्टेटमेंट किसलिए है

यह एक चेकबॉक्स सहेजता है: क्या काउंटर का मालिक ईमेल से साप्ताहिक रिपोर्ट चाहता है। पता एक अलग टेबल में रहता है, और वहाँ पंक्ति तभी बनती है जब कोई व्यक्ति अपने माँगे हुए ईमेल में पुष्टि वाले लिंक पर क्लिक कर दे। चार काउंटरों की ऐसी पंक्ति है। सक्रिय काउंटर 2,218 हैं।

इसलिए 99.8% काउंटरों के लिए UPDATE किसी भी पंक्ति से मेल नहीं खाता। एंडपॉइंट जवाब देता है success: true और सेटिंग सहेजी नहीं जाती, क्योंकि उसे सहेजने की कोई जगह ही नहीं है।

उसके ऊपर लिखी टिप्पणी सही है

तीन लाइन ऊपर, उसी फ़ंक्शन में:

“सिर्फ़ वहीं, जहाँ पुष्टि किया हुआ वापसी पता मौजूद हो। उसके बिना कोई पता नहीं है जिस पर रिपोर्ट भेजी जा सके — और चेकबॉक्स एक ऐसा वादा करता जो पूरा नहीं होता।”

यह बिल्कुल सही है। किसी ने इस स्थिति के बारे में सोचा, उसे समझा और अपना तर्क लिख दिया। फिर ठीक नीचे वाली लाइन में >= लिखा गया, जबकि तर्क के हिसाब से होना चाहिए था >।

इसे सीधे-सीधे देखना ज़रूरी है, क्योंकि आम वजह — किसी ने इस बारे में सोचा ही नहीं — यहाँ भी बताई जा सकती है, पर वह गलत है। सोच फ़ाइल में मौजूद है। चूक एक अक्षर की है, ऐसी जगह पर, जहाँ गलत और सही रूप पहली नज़र में एक जैसे दिखते हैं और हर उस टेस्ट में एक जैसा व्यवहार करते हैं जिसमें अपडेट करने के लिए कोई पंक्ति हो।

किसी से झूठ नहीं बोला जा रहा

अब वह हिस्सा, जिसे छोड़ देना आसान होता, और जिसे छोड़ने से यह पोस्ट ज़्यादा नाटकीय और कम सच्ची हो जाती।

जब तक वह पंक्ति मौजूद न हो, पेज वह चेकबॉक्स दिखाता ही नहीं। कोड में बस एक स्क्रीन दूर, उस हिस्से में जो मालिक का सेटिंग बॉक्स बनाता है, पहले उसी टेबल पर क्वेरी चलती है, और अगर क्वेरी खाली लौटे तो पूरा ब्लॉक छोड़ दिया जाता है। इसलिए बिना पुष्टि किए पते वाला काउंटर का मालिक यह कंट्रोल कभी नहीं देखता, उस पर कभी क्लिक नहीं करता, और उसे कभी झूठी पुष्टि नहीं मिलती।

टूटी हुई जाँच तक सिर्फ़ तभी पहुँचा जा सकता है, जब कोई वैध टोकन के साथ सीधे एंडपॉइंट को कॉल करे। ऐसा करने वाले को मिलता है success: true और कोई सहेजी गई सेटिंग नहीं। यह एक असली खामी है, पर बहुत सीमित।

फिर भी इसे लिखना क्यों ज़रूरी है

यह सुविधा एक ऐसे सुरक्षा-इंतज़ाम की वजह से सुरक्षित है, जिसे किसी ने सुरक्षा-इंतज़ाम के रूप में दर्ज नहीं किया। जो लाइन इसे सुरक्षित बनाने के लिए है, वह इसे सुरक्षित नहीं बनाती। जो चीज़ इसे सुरक्षित बनाती है, वह किसी दूसरे फ़ंक्शन में दिखाने की एक शर्त है, जिसकी टिप्पणी बताती है कि चेकबॉक्स क्यों छिपा है — यह नहीं कि कोई और चीज़ उसके छिपे रहने पर निर्भर है।

अगर दिखाने की वह शर्त हटा दी जाए या बदल दी जाए — जो सेटिंग पैनल को नए सिरे से डिज़ाइन करते समय एक उचित कदम है — तो खामी तुरंत सामने आ जाती है, और कहीं कुछ भी इन दोनों बदलावों को आपस में नहीं जोड़ता। सुरक्षा असली है, पर संयोग से है, और संयोग वाली सुरक्षा ठीक वही होती है जो किसी असंबंधित काम के दौरान गायब हो जाती है।

यही कोडबेस बगल की फ़ाइल में इसे सही तरीके से करता है। वेबरिंग का ऐसा ही फ़ंक्शन पूछता है कि पंक्ति मौजूद है या नहीं, न हो तो false लौटाता है, और अपडेट चलाता ही नहीं। उस टेबल में अभी शून्य पंक्तियाँ हैं, इसलिए वह फ़ंक्शन जब भी बुलाया जाता है, false लौटाता है, और यही सही जवाब है।

आम सबक

जो UPDATE किसी पंक्ति से मेल नहीं खाता, वह किसी भी डेटाबेस में गड़बड़ी नहीं है। वह एक सफल स्टेटमेंट है जिसने कुछ नहीं किया, और उसके ऊपर की हर परत सफलता ही बताएगी, जब तक कोई पूछे नहीं। यहाँ के बाईस स्टेटमेंट नहीं पूछते, और उनमें से ज़्यादातर के लिए यह ठीक है: वे ऐसी पंक्ति अपडेट करते हैं, जिसका मौजूद होना अनुरोध पहले ही साबित कर चुका है।

जिसे पूछना ज़रूरी था, उसने ऐसे तरीके से पूछा जो कभी विफल नहीं हो सकता। rowCount() >= 0 कमज़ोर जाँच नहीं है, यह जाँच की गैरमौजूदगी है जिसने जाँच का भेस पहन रखा है — और यह किसी जाँच के न होने से भी बुरा है, क्योंकि फ़ंक्शन पढ़ने वाला अगला व्यक्ति देखता है कि नतीजा जाँचा जा रहा है, और आगे देखना बंद कर देता है।

इस कोडबेस में rowCount() > 0 शून्य बार आता है। यही वह संख्या है जिसने एक अक्षर की टाइपिंग गलती को पोस्ट लायक बना दिया: यह नहीं कि इसे एक बार गलत लिखा गया, बल्कि यह कि तुलना के लिए कहीं भी इसका कोई सही उदाहरण नहीं था।

28 अगस्त 2026 को ठीक किया गया। अब एंडपॉइंट अपडेट करने से पहले पूछता है कि पंक्ति मौजूद है या नहीं, ठीक वैसे ही जैसे बगल की फ़ाइल वाला वेबरिंग फ़ंक्शन पहले से करता था, और न होने पर false जवाब देता है। एक अक्षर वाला ज़ाहिर सुधार — यानी इसकी जगह शून्य से बड़े की तुलना — पहले मापा गया और खारिज कर दिया गया: ड्राइवर मेल खाई पंक्तियों की नहीं, बल्कि बदली गई पंक्तियों की संख्या बताता है, इसलिए चेकबॉक्स को उसी मान पर सेट करने से, जो उसमें पहले से है, कुछ नहीं बदलता, और वह वर्ज़न एक बिल्कुल ठीक ऑपरेशन के लिए विफलता बताता। दोनों वर्ज़न गलत हैं, उलटी दिशाओं में।