Elevare Digital లోని మీ AI ఏజెంట్ నిష్క్రియాత్మకంగా మారింది ఎందుకంటే కొత్తగా జోడించిన PostgreSQL row-level security (RLS) పాలసీ ప్రతి job rowను ఫిల్టర్ చేసింది, దీనివల్ల క్యూ ఖాళీగా ఉన్నట్లు కనిపించింది. జాబ్స్ పేరుకుపోవడం వరకు ఈ తప్పు గమనించబడలేదు, దీనివల్ల ఆర్కెస్ట్రేటర్ (orchestrator) ఖాళీ క్యూను ఎలా గుర్తిస్తుందో అనే విధానాన్ని రీడిజైన్ చేయాల్సి వచ్చింది.
దాచబడిన బ్లైండ్ స్పాట్ (The hidden blind spot)
ARIA, Elevare యొక్క స్వయంప్రతిపత్త AI వ్యవస్థ, పెండింగ్లో ఉన్న జాబ్స్ కోసం ఒక PostgreSQL టేబుల్ను పోల్ చేస్తుంది (polls). ఆ క్వెరీ విజయవంతమైంది, సున్నా వరుసలను (rows) తిరిగి ఇచ్చింది, మరియు ఏజెంట్ నిష్క్రియాత్మకంగా మారింది. వాస్తవానికి టేబుల్ నిండా డేటా ఉంది. ఒక RLS పాలసీ SELECT యాక్సెస్ను నిర్దిష్ట వినియోగదారుల సమూహానికి మాత్రమే పరిమితం చేసింది. ఆర్కెస్ట్రేటర్ 'bypass privilege' లేని ఒక సర్వీస్ రోల్తో కనెక్ట్ అయ్యింది, కాబట్టి డేటాబేస్ నిశ్శబ్దంగా రిజల్ట్ సెట్ నుండి ప్రతి రోను తొలగించింది. PostgreSQL ఫిల్టర్ చేయబడిన రీడ్ను ఖాళీ టేబుల్తో సమానంగా పరిగణిస్తుంది, కాబట్టి ఎటువంటి ఎర్రర్, వార్నింగ్ లేదా ఫెయిల్యూర్ కోడ్ కనిపించలేదు. నిష్క్రియాత్మకంగా ఉన్న ఏజెంట్ నుండి వచ్చిన హెల్తీ హార్ట్బీట్ (heartbeat), ఏదో తప్పు జరుగుతోందనే సంకేతాన్ని ఇవ్వలేదు.
RLS ఎలా ఒక నిండిన క్యూను నిశ్శబ్దంగా మార్చింది
SELECT చేసేటప్పుడు RLS ప్రతి రోకి ఒక ప్రిడికేట్ను (predicate) జోడిస్తుంది. ఒకవేళ ఆ ప్రిడికేట్ ఫాల్స్ (false) అయితే, ఆ రో ఫలితం నుండి మాయమవుతుంది. పాలసీని సంతృప్తిపరిచే రోలను మాత్రమే క్లయింట్ చూస్తుంది; రోలు దాచబడ్డాయని దానికి ఎప్పటికీ తెలియదు. ఒక క్యూ వర్కర్ కోసం, ఖాళీ రిజల్ట్ సెట్ అనేది నిజంగా ఖాళీగా ఉన్న క్యూలాగే కనిపిస్తుంది. ఆర్కెస్ట్రేటర్ "రోలు లేవు = పని లేదు" అని భావించి తన idle loop లోకి ప్రవేశించింది, అదే సమయంలో జాబ్స్ తెర వెనుక పేరుకుపోతూ ఉన్నాయి.
రీడ్స్ను వ్యక్తిగత వినియోగదారులకు మాత్రమే పరిమితం చేయాలని ఉద్దేశించిన ఒక పాలసీ, అనుకోకుండా సర్వీస్ రోల్ను కూడా దెబ్బతీసిందని టీమ్ కనుగొంది. ఆ రోల్కు ప్రత్యేకమైన “bypass RLS” ఆట్రిబ్యూట్ లేకపోవడం వల్ల, ఆర్కెస్ట్రేటర్ జారీ చేసే ప్రతి క్వెరీకి ఆ పాలసీ వర్తించింది. ఇది క్లాసిక్ సెక్యూరిటీ-వర్సెస్-అబ్జర్వబిలిటీ (security-vs-observability) ట్రేడ్-ఆఫ్ కు ఒక ఉదాహరణ: RLS అనధికారిక వినియోగదారుల నుండి డేటాను రక్షిస్తుంది, కానీ విజిబిలిటీపై ఆధారపడే సిస్టమ్ భాగాలకు అవసరమైన ఫెయిల్యూర్ సిగ్నల్ను కూడా ఇది తొలగిస్తుంది.
ది కెనరీ-చెక్ ప్యాటర్న్ (The canary-check pattern)
నిశ్శబ్దంగా వచ్చే ఖాళీ ఫలితంపై ఆధారపడటాన్ని నివారించడానికి, Elevare ఒక “canary” చెక్ను జోడించింది. కొత్త విధానం ఇది:
- pending-jobs టేబుల్ను క్వెరీ చేయండి.
- రోలు తిరిగి వస్తే, వాటిని మునుపటిలా ప్రాసెస్ చేయండి.
- ఫలితం ఖాళీగా ఉంటే, ఎల్లప్పుడూ ఉండవలసిన ఒక ప్రత్యేకమైన canary row కోసం రెండవ క్వెరీని నిర్వహించండి.
- canary క్వెరీ ఆశించిన రోను తిరిగి ఇస్తే, క్యూ నిజంగా ఖాళీగా ఉన్నట్లు; idle heartbeat ని లాగ్ చేయండి.
- canary క్వెరీ కూడా ఏమీ తిరిగి ఇవ్వకపోతే, ఏజెంట్ అంధంగా (blind) ఉన్నట్లు; వెంటనే అలర్ట్ను పంపండి.
ఇప్పుడు ఆర్కెస్ట్రేటర్ మూడు స్థితిలను (states) వేరు చేయగలదు:
- Jobs found – సాధారణ ప్రాసెసింగ్.
- No jobs, canary OK – నిజమైన నిష్క్రియాత్మక సమయం.
- No jobs, canary failed – దాచబడిన RLS బ్లాక్, అలర్ట్ను ట్రిగ్గర్ చేయండి.
Canary టేబుల్ అనేది ఎప్పుడూ మారని ఒకే ఒక రో. దీనిని సెటప్ చేయడానికి సుమారు గంట సమయం పట్టింది, కానీ ఇది ఒక రకమైన సైలెంట్ ఫెయిల్యూర్స్ను పూర్తిగా నివారిస్తుంది.
టీమ్స్ ఏమి చేయాలి
మీరు PostgreSQL లేదా దానిపై నిర్మించిన హోస్టెడ్ సర్వీస్ (ఉదాహరణకు Supabase) పై క్యూ వర్కర్లను నడుపుతుంటే, ఈ దశలను అనుసరించండి:
- “bypass RLS” ఫ్లాగ్తో ఉన్న service-role credentialను ఉపయోగించండి. ఇది యూజర్-లెవల్ పాలసీలతో సంబంధం లేకుండా సిస్టమ్ భాగాలకు అన్ని రోలను చూడనిస్తుంది.
- సర్వీస్ రోల్స్కు మిస్ అయిన bypass పర్మిషన్ల కోసం RLS పాలసీలను ఆడిట్ చేయండి. ఎండ్ యూజర్లకు సరిగ్గా కనిపించే పాలసీ, అనుకోకుండా అంతర్గత సర్వీసులను ట్రాప్ చేయవచ్చు.
- ఒక canary tableను జోడించండి (లేదా ఎల్లప్పుడూ ఉండే రోను ఉపయోగించండి) మరియు వర్కర్ యొక్క idle లాజిక్లో canary చెక్ను చేర్చండి. ఈ అదనపు క్వెరీ తక్కువ ఖర్చుతో కూడుకున్నది మరియు స్పష్టమైన సేఫ్టీ నెట్ను అందిస్తుంది.
ట్రేడ్-ఆఫ్ (The trade-off)
ఫైన్-గ్రెయిన్డ్ డేటా యాక్సెస్ను అమలు చేయడానికి RLS ఇప్పటికీ ఒక శక్తివంతమైన సాధనం. ఇది అకస్మాత్తుగా డేటా లీక్ అవ్వకుండా నిరోధిస్తుంది మరియు అప్లికేషన్-లెవల్ ఫిల్టర్లను కోడ్బేస్ అంతటా చల్లకుండానే మల్టీ-టెనెంట్ ఆర్కిటెక్చర్లకు మద్దతు ఇస్తుంది. దీని ప్రతికూలత ఏమిటంటే, "రోలు లేవు" అంటే "చేయడానికి ఏమీ లేదు" అని భావించే భాగాలకు ఇది ఫెయిల్యూర్స్ను దాచిపెట్టవచ్చు. Canary ప్యాటర్న్ RLSని బలహీనపరచదు; ఇది అబ్జర్వబిలిటీని పునరుద్ధరించే ఒక తేలికపాటి వెరిఫికేషన్ దశను జోడిస్తుంది.
ముగింపు (Takeaway)
దాచబడిన RLS పాలసీ ఒక బిజీ క్యూను నిశ్శబ్దమైన డెడ్ ఎండ్గా మార్చగలదు, దీనివల్ల పని పేరుకుపోతున్నా AI ఏజెంట్లు నిష్క్రియాత్మకంగా ఉండిపోతాయి. సర్వీస్ రోల్స్కు సరైన bypass ప్రివిలేజ్ను మంజూరు చేయండి మరియు ప్రతి ఖాళీ-క్యూ రీడ్ను canary చెక్తో జత చేయండి; దీనివల్ల టీమ్స్ తమ స్వయంప్రతిపత్త వర్కర్లను సమర్థవంతంగా ఉంచుకోవచ్చు మరియు ఖరీదైన బ్లైండ్ స్పాట్స్ను నివారించవచ్చు.