Elevare Digital-ലെ നിങ്ങളുടെ AI ഏജന്റ് നിഷ്ക്രിയമായി (idle) പോയി. കാരണം പുതുതായി ചേർത്ത PostgreSQL row-level security (RLS) policy എല്ലാ job row-കളെയും ഫിൽട്ടർ ചെയ്തു, ഇത് ക്യൂ ശൂന്യമാണെന്ന് തോന്നിപ്പിച്ചു. ജോലികൾ കുമിഞ്ഞുകൂടുന്നത് വരെ ഈ തെറ്റ് ശ്രദ്ധിക്കപ്പെട്ടില്ല, ഒടുവിൽ ക്യൂ ശൂന്യമാണോ എന്ന് തിരിച്ചറിയുന്ന രീതി മാറ്റാൻ ടീമിന് നിർബന്ധിതമായി.
അദൃശ്യമായ പോരായ്മ
Elevare-ന്റെ സ്വയം പ്രവർത്തിക്കുന്ന (autonomous) AI സിസ്റ്റമായ ARIA, പെൻഡിംഗ് ജോലികൾക്കായി ഒരു PostgreSQL ടേബിൾ പരിശോധിക്കുന്നു (polls). ക്വറി വിജയിച്ചു, പൂജ്യം വരികൾ തിരികെ ലഭിച്ചു, ഏജന്റ് നിഷ്ക്രിയമായി. യഥാർത്ഥത്തിൽ ടേബിൾ നിറഞ്ഞിരിക്കുകയായിരുന്നു. ഒരു RLS policy SELECT ആക്സസ് ഒരു പ്രത്യേക കൂട്ടം ഉപയോക്താക്കളിലേക്ക് മാത്രമായി പരിമിതപ്പെടുത്തിയിരുന്നു. ഓർക്കസ്ട്രേറ്റർ (orchestrator) bypass പ്രിവിലേജ് ഇല്ലാത്ത ഒരു service role ഉപയോഗിച്ചതുകൊണ്ട്, ഡാറ്റാബേസ് റിസൾട്ട് സെറ്റിൽ നിന്ന് എല്ലാ വരികളെയും നിശബ്ദമായി നീക്കം ചെയ്തു. ഫിൽട്ടർ ചെയ്ത ഒരു റീഡിനെ (filtered read) PostgreSQL ഒരു ശൂന്യമായ ടേബിൾ പോലെയാണ് കണക്കാക്കുന്നത്, അതിനാൽ ഒരു എററോ വാർണിംഗോ ഫെയിലർ കോഡോ വന്നില്ല. നിഷ്ക്രിയമായ ഏജന്റിൽ നിന്നുള്ള ഹാർട്ട്ബീറ്റ് (heartbeat) ഒന്നും തെറ്റായതായി സൂചിപ്പിച്ചില്ല.
RLS എങ്ങനെ ഒരു നിറഞ്ഞ ക്യൂയെ നിശബ്ദതയാക്കി മാറ്റി
ഒരു SELECT ചെയ്യുമ്പോൾ ഓരോ വരിയിലും RLS ഒരു predicate ചേർക്കുന്നു. പ്രെഡിക്കേറ്റ് തെറ്റാണെങ്കിൽ (false), ആ വരി റിസൾട്ടിൽ നിന്ന് അപ്രത്യക്ഷമാകും. പോളിസിക്ക് അനുസൃതമായ വരികൾ മാത്രമേ ക്ലയന്റിന് കാണാൻ കഴിയൂ; വരികൾ മറയ്ക്കപ്പെട്ടുവെന്ന് അതിന് അറിയില്ല. ഒരു ക്യൂ വർക്കറെ സംബന്ധിച്ചിടത്തോളം, ശൂന്യമായ ഒരു റിസൾട്ട് സെറ്റ് യഥാർത്ഥത്തിൽ ശൂന്യമായ ഒരു ക്യൂ പോലെ തന്നെയാണ്. "വരികളില്ലെങ്കിൽ ജോലിയില്ല" എന്ന് ഓർക്കസ്ട്രേറ്റർ കരുതി, ജോലികൾ പിന്നിൽ കുമിഞ്ഞുകൂടുമ്പോൾ അത് idle loop-ലേക്ക് പ്രവേശിച്ചു.
വ്യക്തിഗത ഉപയോക്താക്കൾക്ക് മാത്രം റീഡ് ആക്സസ് നൽകാൻ ഉദ്ദേശിച്ച ഒരു പോളിസി അവിചാരിതമായി service role-നെ കൂടി ബാധിച്ചതായി ടീം കണ്ടെത്തി. ആ റോളിന് "bypass RLS" എന്ന പ്രത്യേക ഗുണം ഇല്ലാത്തതിനാൽ, ഓർക്കസ്ട്രേറ്റർ നടത്തുന്ന എല്ലാ ക്വറികൾക്കും പോളിസി ബാധകമായി. ഇത് സുരക്ഷയും നിരീക്ഷണക്ഷമതയും (security-vs-observability) തമ്മിലുള്ള ഒരു ക്ലാസിക് വിട്ടുവീഴ്ചയാണ്: RLS അനധികൃത ഉപയോക്താക്കളിൽ നിന്ന് ഡാറ്റയെ സംരക്ഷിക്കുന്നു, എന്നാൽ സിസ്റ്റം ഘടകങ്ങൾക്ക് ആവശ്യമായ വിസിബിലിറ്റി (visibility) നഷ്ടപ്പെടുത്തുകയും ചെയ്യുന്നു.
കാനറി-ചെക്ക് പാറ്റേൺ (The canary-check pattern)
നിശബ്ദമായ ശൂന്യമായ റിസൾട്ടുകളെ മാത്രം ആശ്രയിക്കുന്നത് ഒഴിവാക്കാൻ Elevare ഒരു “canary” ചെക്ക് ചേർത്തു. പുതിയ രീതി ഇതാണ്:
- പെൻഡിംഗ് ജോലികളുടെ ടേബിൾ ക്വറി ചെയ്യുക.
- വരികൾ ലഭിച്ചാൽ, പഴയതുപോലെ അവ പ്രോസസ്സ് ചെയ്യുക.
- റിസൾട്ട് ശൂന്യമാണെങ്കിൽ, എപ്പോഴും ഉണ്ടായിരിക്കേണ്ട ഒരു പ്രത്യേക canary row-ക്കെതിരെ രണ്ടാമതൊരു ക്വറി നടത്തുക.
- കാനറി ക്വറി പ്രതീക്ഷിച്ച വരി നൽകുന്നുണ്ടെങ്കിൽ, ക്യൂ ശരിക്കും ശൂന്യമാണ്; ഒരു idle heartbeat ലോഗ് ചെയ്യുക.
- കാനറി ക്വറിയിൽ നിന്നും ഒന്നും ലഭിച്ചില്ലെങ്കിൽ, ഏജന്റ് അന്ധനാണ് (blind); ഉടൻ തന്നെ ഒരു അലേർട്ട് നൽകുക.
ഇപ്പോൾ ഓർക്കസ്ട്രേറ്റർ മൂന്ന് അവസ്ഥകൾ തിരിച്ചറിയുന്നു:
- Jobs found – സാധാരണ പ്രോസസ്സിംഗ്.
- No jobs, canary OK – യഥാർത്ഥമായ നിഷ്ക്രിയ സമയം.
- No jobs, canary failed – മറഞ്ഞിരിക്കുന്ന RLS ബ്ലോക്ക്, അലേർട്ട് നൽകുക.
കാനറി ടേബിൾ എന്നത് ഒരിക്കലും മാറാത്ത ഒരു സിംഗിൾ റോ ആണ്. ഇത് സെറ്റ് ചെയ്യാൻ ഏകദേശം ഒരു മണിക്കൂർ എടുത്തു, എന്നാൽ ഇത് ഇത്തരം നിശബ്ദമായ പരാജയങ്ങളെ പൂർണ്ണമായും ഒഴിവാക്കുന്നു.
ടീമുകൾ എന്തുചെയ്യണം
നിങ്ങൾ PostgreSQL അല്ലെങ്കിൽ അതിന്മേൽ നിർമ്മിച്ച ഒരു ഹോസ്റ്റഡ് സർവീസ് (ഉദാഹരണത്തിന് Supabase) ഉപയോഗിച്ച് ക്യൂ വർക്കറുകൾ പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിൽ, ഈ ഘട്ടങ്ങൾ പാലിക്കുക:
- "bypass RLS" ഫ്ലാഗുള്ള ഒരു service-role credential ഉപയോഗിക്കുക. ഇത് ഉപയോക്തൃതല പോളിസികൾ പരിഗണിക്കാതെ തന്നെ സിസ്റ്റം ഘടകങ്ങൾക്ക് എല്ലാ വരികളും കാണാൻ അനുവദിക്കുന്നു.
- സർവീസ് റോൾസുകൾക്ക് ബൈപാസ് പെർമിഷനുകൾ ഇല്ലെന്ന് ഉറപ്പാക്കാൻ RLS policies ഓഡിറ്റ് ചെയ്യുക. സാധാരണ ഉപയോക്താക്കൾക്ക് ശരിയായി തോന്നുന്ന ഒരു പോളിസി അവിചാരിതമായി ഇന്റേണൽ സർവീസുകളെ തടഞ്ഞേക്കാം.
- ഒരു canary table (അല്ലെങ്കിൽ എപ്പോഴും നിലവിലുള്ള ഒരു വരി) ചേർക്കുകയും വർക്കറുടെ idle ലോജിക്കിൽ കാനറി ചെക്ക് ഉൾപ്പെടുത്തുകയും ചെയ്യുക. ഈ അധിക ക്വറി വളരെ ലളിതമാണ്, കൂടാതെ ഇത് മികച്ച സുരക്ഷ ഉറപ്പാക്കുന്നു.
വിട്ടുവീഴ്ച (The trade-off)
സൂക്ഷ്മമായ ഡാറ്റാ ആക്സസ് നടപ്പിലാക്കാൻ RLS ഇപ്പോഴും ശക്തമായ ഒരു ഉപകരണമാണ്. ഇത് അവിചാരിതമായ ഡാറ്റാ ചോർച്ച തടയുകയും കോഡ്ബേസിലുടനീളം ഫിൽട്ടറുകൾ ചേർക്കാതെ തന്നെ മൾട്ടി-ടെനന്റ് ആർക്കിടെക്ചറുകളെ പിന്തുണയ്ക്കുകയും ചെയ്യുന്നു. എന്നാൽ "വരികളില്ല" എന്ന സിഗ്നലിനെ "ചെയ്യാനൊന്നുമില്ല" എന്ന് തെറ്റായി വ്യാഖ്യാനിക്കുന്ന സിസ്റ്റം ഘടകങ്ങളിൽ നിന്ന് പരാജയങ്ങളെ മറച്ചുവെക്കാൻ ഇതിന് സാധിക്കും. കാനറി പാറ്റേൺ RLS-നെ ദുർബലപ്പെടുത്തുന്നില്ല; പകരം നിരീക്ഷണക്ഷമത (observability) വീണ്ടെടുക്കുന്നതിനുള്ള ഒരു ലഘുവായ പരിശോധനയാണ് ഇത് നൽകുന്നത്.
ചുരുക്കം (Takeaway)
മറഞ്ഞിരിക്കുന്ന ഒരു RLS policy തിരക്കുള്ള ഒരു ക്യൂയെ നിശബ്ദമായ ഒരു തടസ്സമാക്കി മാറ്റുകയും, ജോലികൾ കുമിഞ്ഞുകൂടുമ്പോൾ AI ഏജന്റുകളെ നിഷ്ക്രിയമാക്കുകയും ചെയ്യാം. സർവീസ് റോൾസുകൾക്ക് ശരിയായ bypass പ്രിവിലേജ് നൽകുകയും ഓരോ ശൂന്യമായ ക്യൂ റീഡിനൊപ്പവും ഒരു കാനറി ചെക്ക് ഉപയോഗിക്കുകയും ചെയ്യുക; അതുവഴി ടീമുകൾക്ക് അവരുടെ ഓട്ടോണമസ് വർക്കറുകളെ കൃത്യമായി പ്രവർത്തിപ്പിക്കാനും വലിയ പിഴവുകൾ ഒഴിവാക്കാനും കഴിയും.