SQLite-ன் LIKE patterns-ல் இருந்த ஒரு மறைமுகமான 50-byte வரம்பு, Agentic Inbox திட்டம் நீண்ட மின்னஞ்சல் தலைப்புகளைத் தேட முயன்றபோது Cloudflare Workers-ஐச் செயலிழக்கச் செய்தது; தேடல் சரங்களை (search strings) 48 எழுத்துக்களாகக் குறைத்தது இந்தத் தோல்விகளைத் தடுத்தது.

எட்ஜ் ரன்டைமை (edge runtime) உடைத்தது எது

Agentic Inbox ஒவ்வொரு மெயில் பாக்ஸையும் (mailbox) சேமிப்பிற்காக ஒரு உட்பொதிக்கப்பட்ட (embedded) SQLite தரவுத்தளத்தைப் பயன்படுத்தி, Cloudflare Durable Object-க்குள் இயக்குகிறது. AI-ஆல் இயக்கப்படும் இந்த ஏஜென்ட், தேடல் முறையை (search pattern) %search_term% என உருவாக்குகிறது. LIKE pattern-ன் மொத்த நீளத்திற்கு SQLite ஒரு கடுமையான 50-byte வரம்பை விதிக்கிறது. ஒரு பயனர் 48 எழுத்துக்களுக்கு மேல் நீளமான தலைப்பை உள்ளிடும்போது, அதைச் சுற்றியுள்ள % குறிகள் அந்த வரம்பைத் தாண்டிச் சென்றன. SQLite ஒரு கையாளப்படாத ரன்டைம் பிழையை (unhandled runtime error) ஏற்படுத்தியது, அதை அந்த வரையறுக்கப்பட்ட Worker சூழல் ஒரு கடுமையான (fatal) பிழையாகக் கருதியது. இதனால் முழு ஸ்கிரிப்ட்டும் நின்றுபோய், இன்பாக்ஸைப் பயன்படுத்த முடியாத நிலையையும் AI ஏஜென்ட் செயலிழந்த நிலையையும் உருவாக்கியது.

பிழை எவ்வாறு கண்டறியப்பட்டது

Sentry, Workers-லிருந்து வந்த கையாளப்படாத விதிவிலக்குகளை (uncaught exceptions) பதிவு செய்தது. செயலிழப்பு ஏற்பட்டபோது, SQLite பிழையை ஏற்படுத்திய துல்லியமான வரியை Sentry பதிவு செய்தது. அதன் “Seer AI” அம்சம் stack trace-ஐப் பகுப்பாய்வு செய்து, LIKE pattern உருவாக்கத்தை முன்னிலைப்படுத்தியதுடன், pattern நீளமே இதற்குக் காரணம் என்று பரிந்துரைத்தது. SQLite-ன் compile-time ஆவணங்களைச் சரிபார்த்தபோது அந்த 50-byte கட்டுப்பாடு உறுதி செய்யப்பட்டது. பின்னர், அந்த வரம்பைச் சரிபார்க்கவும், பயனர் உள்ளீட்டிற்கான பாதுகாப்பான அதிகபட்ச நீளத்தைக் கணக்கிடவும் குழு Gemini-யைப் பயன்படுத்தியது.

துல்லியமான தீர்வு

இந்தத் தீர்வுக்குத் தற்போதுள்ள தேடல் நடைமுறையிலேயே (search routine) மூன்று சிறிய மாற்றங்கள் தேவைப்பட்டன:

  • வரும் எந்தவொரு தேடல் சொல்லுக்கும் (search term) 48 எழுத்துக்களுக்கு மேல் இருக்கக்கூடாது என்ற கடுமையான வரம்பை விதித்தல்.
  • % wildcards-களை இணைப்பதற்கு முன், உள்ளீட்டு சரத்தை (input string) அந்த நீளத்திற்குச் சுருக்குதல்.
  • புதிய லைப்ரரிகளைச் சேர்க்காமல், தேடல் துல்லியத்தைப் பேணுவதற்காக மீதமுள்ள வினவலை (query) மாற்றமில்லாமல் அப்படியே வைத்தல்.

இந்த மாற்றமானது வினவல் (query) SQLite-ஐச் சென்றடைவதற்கு முன்பே நடப்பதால், இறுதி pattern ஒருபோதும் 50-byte வரம்பைத் தாண்டாது, இதனால் Worker இனி செயலிழக்காது. கூடுதல் சார்புகள் (dependencies) எதுவும் சேர்க்கப்படவில்லை, எனவே codebase இலகுவாகவே உள்ளது.

இது ஏன் முக்கியமானது

குறைந்த தாமதத் தேவைக்காக (low-latency use cases) எட்ஜ்-ஹோஸ்டட் (Edge-hosted) தரவுத்தளங்கள் ஈர்க்கக்கூடியவை, ஆனால் அவை ஆன்-பிரமிஸ் (on-premises) பதிப்புகளைப் போன்ற அதே கட்டுப்பாடுகளைக் கொண்டுள்ளன. ஒரு ரன்டைம் கையாளப்படாத எந்தவொரு விதிவிலக்கையும் fatal பிழையாகக் கருதும்போது, ஒரு தெளிவற்ற compile-time வரம்பு, தயாரிப்புச் சூழலில் (production) வேலையைத் தடுக்கும் பிழையாக மாறக்கூடும். இங்கே, நீண்ட தலைப்பைத் தட்டச்சு செய்த எந்தவொரு பயனருக்கும் AI-ஆல் இயங்கும் மின்னஞ்சல் உதவியாளர் வேலை செய்வதைத் இந்தச் செயலிழப்பு தடுத்தது—இது பயனர் அனுபவம் மற்றும் சர்வர்லெஸ் (serverless) தளங்களின் நம்பகத்தன்மைக்கு நேரடித் தாக்கமாகும்.

வேறு என்ன செய்ய முடிந்திருக்கும்

தீர்வு எளிமையானதுதான், ஆனால் இது விடுபட்ட ஒரு சரிபார்ப்புப் படிநிலையை (validation step) சுட்டிக்காட்டுகிறது. SQL சரத்தை உருவாக்குவதற்கு முன்பே pattern நீளத்தைச் சரிபார்க்கும் உள்ளீட்டுத் தூய்மைப்படுத்துதல் (Input sanitization) முறையைப் பயன்படுத்தியிருந்தால், தயாரிப்புச் சூழலில் சிக்கல் ஏற்படுவதற்கு முன்பே மேம்பாட்டு நிலையிலேயே (development) இதைக் கண்டறிந்திருக்கலாம்.

அடுத்து எவற்றைக் கவனிக்க வேண்டும்

எட்ஜ் ரன்டைம்களில் SQLite-ஐப் பயன்படுத்தும் டெவலப்பர்கள், pattern matching தொடர்பான அனைத்து வினவல் கட்டமைப்புகளையும் (query constructions) தணிக்கை செய்ய வேண்டும், குறிப்பாக wildcards அல்லது escape characters-களைச் சேர்க்கும் கட்டமைப்புகளைக் கவனிக்க வேண்டும். SQLite தோல்வியடைந்த துல்லியமான வரியை Sentry கண்டறிந்தது. எட்ஜ் கம்ப்யூட்டிங் (edge computing) பிரபலமடையும் போது, மறைமுகமான பிளாட்ஃபார்ம் வரம்புகள் அடிக்கடி வெளிப்படும், எனவே ஆவணப்படுத்தப்பட்ட கட்டுப்பாடுகளுக்கு எதிராக உள்ளீடுகளைச் சரிபார்க்கும் பழக்கம் பயனளிக்கும்.

சுருக்கம்: SQLite LIKE patterns-ல் உள்ள 50-byte வரம்பு Cloudflare Workers-ஐச் செயலிழக்கச் செய்யலாம், ஆனால் தேடல் சொற்களை 48 எழுத்துக்களாகக் குறைப்பதன் மூலம் கூடுதல் சுமை இன்றி இந்தப் பிழையைத் தவிர்க்கலாம்—ஒரு சிறிய சரிபார்ப்புப் படிநிலை எட்ஜ் சேவைகளை நிலையாக வைத்திருக்க முடியும் என்பதற்கு இதுவே சான்று.