Elevare Digital में आपका AI एजेंट निष्क्रिय (idle) हो गया क्योंकि एक नई जोड़ी गई PostgreSQL row-level security (RLS) पॉलिसी ने हर जॉब रो (job row) को फ़िल्टर कर दिया, जिससे कतार (queue) खाली दिखाई देने लगी। यह गलती तब तक नज़र नहीं आई जब तक कि काम (jobs) जमा नहीं होने लगे, जिससे टीम को ऑर्केस्ट्रेटर (orchestrator) द्वारा खाली कतार का पता लगाने के तरीके को फिर से डिज़ाइन करने के लिए मजबूर होना पड़ा।
छिपा हुआ ब्लाइंड स्पॉट
ARIA, Elevare का स्वायत्त (autonomous) AI सिस्टम, पेंडिंग जॉब्स के लिए एक PostgreSQL टेबल को पोल (poll) करता है। क्वेरी सफल रही, शून्य रो (rows) वापस मिलीं, और एजेंट सो गया। वास्तव में टेबल भरी हुई थी। एक RLS पॉलिसी ने SELECT एक्सेस को उपयोगकर्ताओं के एक विशिष्ट सेट तक सीमित कर दिया था। ऑर्केस्ट्रेटर एक सर्विस रोल (service role) के साथ जुड़ा था जिसके पास 'bypass privilege' नहीं था, इसलिए डेटाबेस ने परिणाम सेट (result set) से चुपचाप हर रो को हटा दिया। PostgreSQL फ़िल्टर किए गए रीड (read) को खाली टेबल के समान ही मानता है, इसलिए कोई एरर, चेतावनी या फेलियर कोड दिखाई नहीं दिया। निष्क्रिय एजेंट से मिलने वाले एक सामान्य हार्टबीट (heartbeat) से इस बात का कोई संकेत नहीं मिला कि कुछ गलत था।
RLS ने भरी हुई कतार को सन्नाटे में कैसे बदल दिया
RLS एक SELECT के दौरान प्रत्येक रो में एक प्रेडिकेट (predicate) जोड़ता है। यदि प्रेडिकेट 'false' है, तो रो परिणाम से गायब हो जाती है। क्लाइंट केवल उन्हीं रो को देखता है जो पॉलिसी को पूरा करती हैं; उसे कभी पता नहीं चलता कि रो छिपी हुई थीं। एक कतार वर्कर (queue worker) के लिए, एक खाली परिणाम सेट बिल्कुल एक वास्तविक खाली कतार जैसा दिखता है। ऑर्केस्ट्रेटर ने माना कि “कोई रो नहीं = कोई काम नहीं” और वह अपने आइडल लूप (idle loop) में चला गया, जबकि पर्दे के पीछे काम (jobs) जमा होते रहे।
टीम ने पाया कि व्यक्तिगत उपयोगकर्ताओं तक रीड (reads) को सीमित करने के लिए बनाई गई एक पॉलिसी ने अनजाने में सर्विस रोल को ही पकड़ लिया था। क्योंकि उस रोल में विशेष “bypass RLS” एट्रिब्यूट नहीं था, इसलिए पॉलिसी ऑर्केस्ट्रेटर द्वारा जारी की गई हर क्वेरी पर लागू हो गई। यह सुरक्षा बनाम अवलोकन (security-vs-observability) के क्लासिक ट्रेड-ऑफ को दर्शाता है: RLS अनधिकृत उपयोगकर्ताओं से डेटा की रक्षा करता है, लेकिन यह उन सिस्टम घटकों के लिए एक उपयोगी विफलता संकेत (failure signal) को भी हटा देता है जो विज़िबिलिटी (visibility) पर निर्भर करते हैं।
कैनरी-चेक पैटर्न
एक शांत खाली परिणाम पर निर्भरता को तोड़ने के लिए, Elevare ने एक “कैनरी” (canary) चेक जोड़ा। नया फ्लो इस प्रकार है:
- पेंडिंग-जॉब्स टेबल को क्वेरी करें।
- यदि रो वापस मिलती हैं, तो उन्हें पहले की तरह प्रोसेस करें।
- यदि परिणाम खाली है, तो एक समर्पित कैनरी रो (canary row) के विरुद्ध दूसरी क्वेरी जारी करें जो हमेशा मौजूद होनी चाहिए।
- यदि कैनरी क्वेरी अपेक्षित रो वापस करती है, तो कतार वास्तव में खाली है; एक आइडल हार्टबीट लॉग करें।
- यदि कैनरी क्वेरी भी कुछ नहीं लौटाती है, तो एजेंट अंधा (blind) है; तुरंत अलर्ट जारी करें।
अब ऑर्केस्ट्रेटर तीन स्थितियों में अंतर करता है:
- जॉब्स मिले – सामान्य प्रोसेसिंग।
- कोई जॉब नहीं, कैनरी OK – वास्तविक आइडल अवधि।
- कोई जॉब नहीं, कैनरी विफल – छिपा हुआ RLS ब्लॉक, अलर्ट ट्रिगर करें।
कैनरी टेबल एक सिंगल रो है जो कभी नहीं बदलती। इसे सेटअप करने में लगभग एक घंटा लगा, लेकिन यह साइलेंट फेलियर (silent failures) की एक पूरी श्रेणी को समाप्त कर देता है।
टीमों को क्या करना चाहिए
यदि आप PostgreSQL या उस पर बने किसी होस्टेड सर्विस (जैसे Supabase) के खिलाफ कतार वर्कर चलाते हैं, तो इन चरणों का पालन करें:
- “bypass RLS” फ्लैग के साथ सर्विस-रोल क्रेडेंशियल का उपयोग करें। यह सिस्टम घटकों को यूजर-लेवल पॉलिसी के बावजूद सभी रो देखने की अनुमति देता है।
- सर्विस रोल्स के लिए मिसिंग बाईपास परमिशन के लिए RLS पॉलिसीज़ का ऑडिट करें। एक पॉलिसी जो एंड-यूज़र्स के लिए सही लगती है, वह अनजाने में आंतरिक सेवाओं को फँसा सकती है।
- एक कैनरी टेबल जोड़ें (या इसके समकक्ष हमेशा मौजूद रहने वाली रो) और वर्कर के आइडल लॉजिक में कैनरी चेक को शामिल करें। अतिरिक्त क्वेरी सस्ती है और एक स्पष्ट सुरक्षा जाल (safety net) प्रदान करती है।
ट्रेड-ऑफ
RLS बारीक-स्तर (fine-grained) के डेटा एक्सेस को लागू करने के लिए एक शक्तिशाली उपकरण बना हुआ है। यह आकस्मिक डेटा लीक को रोकता है और पूरे कोडबेस में एप्लिकेशन-लेवल फ़िल्टर बिखेरे बिना मल्टी-टेनेंट आर्किटेक्चर का समर्थन करता है। इसका नुकसान यह है कि यह उन घटकों से विफलताओं को छिपा सकता है जो "कोई रो नहीं" सिग्नल का अर्थ "करने के लिए कुछ नहीं" समझते हैं। कैनरी पैटर्न RLS को कमजोर नहीं करता है; यह एक हल्का सत्यापन चरण जोड़ता है जो ऑब्जर्वेबिलिटी (observability) को बहाल करता है।
निष्कर्ष
एक छिपी हुई RLS पॉलिसी एक व्यस्त कतार को एक शांत डेड एंड (dead end) में बदल सकती है, जिससे काम जमा होने के बावजूद AI एजेंट निष्क्रिय रह जाते हैं। सर्विस रोल्स को उचित बाईपास विशेषाधिकार दें और हर खाली-कतार रीड (empty-queue read) को कैनरी चेक के साथ जोड़ें; टीमें अपने स्वायत्त वर्कर्स को सटीक रख सकती हैं और महंगे ब्लाइंड स्पॉट से बच सकती हैं।