Elevare Digital-இல் உள்ள உங்கள் AI ஏஜென்ட் செயலற்ற நிலையில் (idle) இருந்தது, ஏனெனில் புதிதாக சேர்க்கப்பட்ட PostgreSQL row-level security (RLS) கொள்கை (policy) அனைத்து வேலை வரிசைகளையும் (job rows) வடிகட்டியது, இதனால் வரிசை காலியாக இருப்பது போல் தோன்றியது. வேலைகள் குவிந்து சேரும் வரை இந்தத் தவறு கவனிக்கப்படவில்லை, இது இறுதியில் orchestrator எவ்வாறு காலியான வரிசையைக் கண்டறிய வேண்டும் என்பதை மறுவடிவமைப்பு செய்ய குழுவை வற்புறுத்தியது.
மறைக்கப்பட்ட பார்வையின்றித் தெரியாத புள்ளி
Elevare-இன் தன்னாட்சி AI அமைப்பான ARIA, நிலுவையில் உள்ள வேலைகளுக்காக (pending jobs) ஒரு PostgreSQL அட்டவணையைத் தொடர்ந்து சரிபார்க்கிறது (polls). அந்தத் தேடல் (query) வெற்றிகரமாக முடிந்தது, ஆனால் பூஜ்ஜிய வரிசைகளைத் திரும்பப் பெற்றது, இதனால் ஏஜென்ட் செயலற்ற நிலைக்குச் சென்றது. உண்மையில் அந்த அட்டவணை நிரம்பி இருந்தது. ஒரு RLS கொள்கை, குறிப்பிட்ட பயனர்களுக்கு மட்டுமே SELECT அணுகலை மட்டுப்படுத்தியிருந்தது. Orchestrator, 'bypass privilege' இல்லாத ஒரு service role மூலம் இணைக்கப்பட்டிருந்தது, எனவே தரவுத்தளம் (database) முடிவுகளில் இருந்து ஒவ்வொரு வரிசையையும் அமைதியாக நீக்கியது. PostgreSQL, வடிகட்டப்பட்ட ஒரு வாசிப்பை (filtered read) காலியான அட்டவணை போலவே கருதுகிறது, எனவே எந்தத் தவறு (error), எச்சரிக்கை (warning) அல்லது தோல்வி குறியீடும் (failure code) தோன்றவில்லை. செயலற்ற நிலையில் இருந்த ஏஜென்டிலிருந்து வந்த இயல்பான 'heartbeat' சிக்னல், ஏதோ தவறு நடப்பதாக எந்தத் தகவலையும் வழங்கவில்லை.
RLS எவ்வாறு நிரம்பி வழியும் வரிசையை அமைதியாக மாற்றியது
ஒரு SELECT செயல்பாட்டின் போது, RLS ஒவ்வொரு வரிசைக்கும் ஒரு நிபந்தனையை (predicate) சேர்க்கிறது. அந்த நிபந்தனை தவறாக இருந்தால், அந்த வரிசை முடிவிலிருந்து மறைந்துவிடும். கொள்கையை பூர்த்தி செய்யும் வரிசைகளை மட்டுமே கிளையன்ட் (client) பார்க்க முடியும்; வரிசைகள் மறைக்கப்பட்டிருப்பதை அது அறியாது. ஒரு queue worker-க்கு, காலியான முடிவுத் தொகுப்பு (empty result set) என்பது உண்மையாகவே காலியான வரிசை போன்றே தோன்றும். "வரிசைகள் இல்லை = வேலை இல்லை" என்று கருதிய orchestrator, அதன் idle loop-க்குள் சென்றது, ஆனால் வேலைகள் பின்னணியில் குவிந்து கொண்டே இருந்தன.
தனிப்பட்ட பயனர்களுக்கு மட்டும் வாசிப்பைக் கட்டுப்படுத்த உருவாக்கப்பட்ட ஒரு கொள்கை, எதிர்பாராதவிதமாக service role-ஐயும் பாதித்திருப்பதை குழு கண்டறிந்தது. அந்த role-இல் சிறப்பு "bypass RLS" பண்பு (attribute) இல்லாததால், orchestrator அனுப்பும் ஒவ்வொரு query-க்கும் அந்தப் கொள்கை பொருந்தியது. இது பாதுகாப்பு மற்றும் கண்காணிப்பு (security-vs-observability) இடையிலான ஒரு பாரம்பரிய சமநிலையை (trade-off) விளக்குகிறது: RLS அங்கீகரிக்கப்படாத பயனர்களிடமிருந்து தரவைப் பாதுகாக்கிறது, ஆனால் அதே சமயம் வெளிப்படைத்தன்மையை (visibility) நம்பியிருக்கும் கணினி கூறுகளுக்குத் தேவையான பயனுள்ள தோல்வி சிக்னலையும் (failure signal) அது நீக்கிவிடுகிறது.
Canary-check முறை
அமைதியான காலியான முடிவுகளைச் சார்ந்திருப்பதைத் தவிர்க்க, Elevare ஒரு "canary" சரிபார்ப்பைச் சேர்த்தது. புதிய செயல்முறை (flow) இதோ:
- நிலுவையில் உள்ள வேலைகளின் (pending-jobs) அட்டவணையைத் தேடவும் (Query).
- வரிசைகள் திரும்பப் பெற்றால், முன்பைப் போலவே அவற்றைச் செயல்படுத்தவும்.
- முடிவு காலியாக இருந்தால், எப்போதும் இருக்க வேண்டிய ஒரு பிரத்யேக canary வரிசைக்கு எதிராக இரண்டாவது தேடலை (query) மேற்கொள்ளவும்.
- canary query எதிர்பார்த்த வரிசையைத் திரும்பப் பெற்றால், வரிசை உண்மையாகவே காலியாக உள்ளது; ஒரு idle heartbeat-ஐப் பதிவு செய்யவும்.
- canary query-யும் எதையும் திரும்பப் பெறவில்லை என்றால், ஏஜென்ட் பார்வையின்றித் தெரியாத நிலையில் (blind) உள்ளது; உடனடியாக ஒரு எச்சரிக்கையை (alert) வழங்கவும்.
இப்போது orchestrator மூன்று நிலைகளை வேறுபடுத்துகிறது:
- வேலைகள் கண்டறியப்பட்டன (Jobs found) – இயல்பான செயல்முறை.
- வேலைகள் இல்லை, canary OK – உண்மையான செயலற்ற காலம் (idle period).
- வேலைகள் இல்லை, canary தோல்வியடைந்தது – மறைக்கப்பட்ட RLS தடுப்பு, எச்சரிக்கையைத் தூண்டவும்.
Canary அட்டவணை என்பது ஒருபோதும் மாறாத ஒரு தனி வரிசையாகும். இதை அமைப்பதற்கு சுமார் ஒரு மணிநேரம் எடுத்தது, ஆனால் இது ஒரு வகை அமைதியான தோல்விகளை (silent failures) முற்றிலுமாகத் தவிர்க்கிறது.
குழுக்கள் என்ன செய்ய வேண்டும்
நீங்கள் PostgreSQL அல்லது அதன் அடிப்படையில் உருவாக்கப்பட்ட ஒரு ஹோஸ்டு சேவையை (உதாரணமாக Supabase) பயன்படுத்தி queue workers-களை இயக்கினால், இந்த வழிமுறைகளைப் பின்பற்றவும்:
- "bypass RLS" flag கொண்ட service-role சான்றுகளைப் (credential) பயன்படுத்தவும். இது பயனர்-நிலை கொள்கைகளைப் பொருட்படுத்தாமல் கணினி கூறுகளுக்கு அனைத்து வரிசைகளையும் பார்க்க அனுமதிக்கிறது.
- Service roles-களுக்குத் தேவையான bypass அனுமதிகள் விடுபட்டுள்ளதா என்பதைச் சரிபார்க்க RLS கொள்கைகளைத் தணிக்கை (Audit) செய்யவும். இறுதிப் பயனர்களுக்குச் சரியாகத் தோன்றும் ஒரு கொள்கை, எதிர்பாராதவிதமாக உள் சேவைகளை (internal services) சிக்க வைப்பக்கூடும்.
- ஒரு canary அட்டவணையைச் (அல்லது எப்போதும் இருக்கும் ஒரு சமமான வரிசையை) சேர்க்கவும் மற்றும் worker-இன் idle logic-இல் canary சரிபார்ப்பைச் சேர்க்கவும். இந்த கூடுதல் query செலவு குறைவானது மற்றும் தெளிவான பாதுகாப்பு வலையமைப்பை (safety net) வழங்குகிறது.
சமநிலை (The trade-off)
நுணுக்கமான தரவு அணுகலை (fine-grained data access) நடைமுறைப்படுத்துவதற்கு RLS ஒரு சக்திவாய்ந்த கருவியாகத் தொடர்கிறது. இது தற்செயலான தரவு கசிவைத் தடுக்கிறது மற்றும் codebase முழுவதும் application-level வடிகட்டிகளைத் தெளிக்காமலேயே multi-tenant கட்டமைப்புகளை ஆதரிக்கிறது. இதன் குறைபாடு என்னவென்றால், "வரிசைகள் இல்லை" என்ற சிக்னலை "செய்ய வேண்டியது எதுவும் இல்லை" என்று கருதும் கூறுகளிடமிருந்து (components) தோல்விகளை இது மறைக்கக்கூடும். Canary முறை RLS-ஐ வலுவிழக்கச் செய்யாது; மாறாக, அது கண்காணிப்புத் திறனை (observability) மீட்டெடுக்கும் ஒரு இலகுவான சரிபார்ப்புப் படிநிலையைச் சேர்க்கிறது.
முக்கியக் கருத்து (Takeaway)
ஒரு மறைக்கப்பட்ட RLS கொள்கை, பரபரப்பான வரிசையை ஒரு அமைதியான முட்டுச்சந்தையாக மாற்றக்கூடும், இதனால் வேலைகள் தேங்கிக் கொண்டிருக்கும்போது AI ஏஜென்ட்கள் செயலற்ற நிலையில் இருக்கும். Service roles-களுக்குச் சரியான bypass அனுமதியை வழங்கவும் மற்றும் ஒவ்வொரு காலியான வரிசை வாசிப்பையும் (empty-queue read) ஒரு canary சரிபார்ப்புடன் இணைக்கவும்; இதன் மூலம் குழுக்கள் தங்கள் தன்னாட்சிப் பணியாளர்களைச் சரியாகச் செயல்பட வைக்க முடியும் மற்றும் விலை உயர்ந்த பார்வையின்றித் தெரியாத பகுதிகளைத் தவிர்க்க முடியும்.