SQLite-ന്റെ LIKE പാറ്റേണുകളിലെ ഒളിഞ്ഞിരിക്കുന്ന 50-ബൈറ്റ് പരിധി കാരണം, Agentic Inbox പ്രോജക്റ്റ് നീളമുള്ള ഇമെയിൽ വിഷയങ്ങൾ തിരയാൻ ശ്രമിച്ചപ്പോൾ Cloudflare Workers തകരാറിലായി (crash). തിരയുന്ന സ്ട്രിംഗുകൾ 48 ക്യാരക്ടറുകളായി പരിമിതപ്പെടുത്തിയതോടെ ഈ പ്രശ്നം പരിഹരിക്കപ്പെട്ടു.

എഡ്ജ് റൺടൈമിനെ (edge runtime) തകരാറിലാക്കിയത് എന്താണ്

Agentic Inbox ഓരോ മെയിൽബോക്സും ഒരു Cloudflare Durable Object-നുള്ളിൽ പ്രവർത്തിപ്പിക്കുന്നു, ഇതിനായി സ്റ്റോറേജിനായി ഒരു എംബഡഡ് SQLite ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നു. AI അധിഷ്ഠിത ഏജന്റ് %search_term% എന്ന രീതിയിൽ ഒരു സെർച്ച് പാറ്റേൺ നിർമ്മിക്കുന്നു. ഒരു LIKE പാറ്റേണിന്റെ ആകെ നീളത്തിന് SQLite 50-ബൈറ്റ് എന്ന കർശനമായ പരിധി ഏർപ്പെടുത്തിയിട്ടുണ്ട്. ഒരു ഉപയോക്താവ് 48 ക്യാരക്ടറുകളേക്കാൾ നീളമുള്ള ഒരു വിഷയം (subject) നൽകിയാൽ, അതിനോടൊപ്പമുള്ള % ചിഹ്നങ്ങൾ പാറ്റേണിനെ ആ പരിധിക്ക് അപ്പുറത്തേക്ക് എത്തിക്കുന്നു. SQLite ഒരു അൺഹാൻഡിൽഡ് റൺടൈം എറർ (unhandled runtime error) പുറപ്പെടുവിച്ചു, ഇത് പരിമിതമായ Worker എൻവയോൺമെന്റ് ഒരു ഗുരുതരമായ പിശകായി (fatal error) കണക്കാക്കി. മുഴുവൻ സ്ക്രിപ്റ്റും നിർത്തിവെച്ചതോടെ ഇൻബോക്സ് ഉപയോഗശൂന്യമാവുകയും AI ഏജന്റ് പ്രവർത്തനരഹിതമാവുകയും ചെയ്തു.

ബഗ് എങ്ങനെ കണ്ടെത്തി

Workers-ൽ നിന്നുള്ള അൺകാറ്റ് എക്സെപ്ഷനുകൾ (uncaught exceptions) Sentry രേഖപ്പെടുത്തി. ക്രാഷ് സംഭവിച്ചപ്പോൾ, SQLite എറർ കാണിച്ച കൃത്യമായ വരി Sentry രേഖപ്പെടുത്തി. അതിന്റെ “Seer AI” ഫീച്ചർ സ്റ്റാക്ക് ട്രാസ് (stack trace) വിശകലനം ചെയ്യുകയും, LIKE പാറ്റേൺ നിർമ്മാണത്തെ എടുത്തു കാണിക്കുകയും, പാറ്റേൺ നീളമാണ് പ്രശ്നകാരണമെന്ന് നിർദ്ദേശിക്കുകയും ചെയ്തു. SQLite-ന്റെ കംപൈൽ-ടൈം ഡോക്യുമെന്റേഷൻ പരിശോധിച്ചപ്പോൾ 50-ബൈറ്റ് നിയന്ത്രണം സ്ഥിരീകരിക്കപ്പെട്ടു. തുടർന്ന്, ഈ പരിധി പരിശോധിക്കാനും ഉപയോക്താവിന്റെ ഇൻപുട്ടിന് സുരക്ഷിതമായ പരമാവധി നീളം കണക്കാക്കാനും ടീം Gemini ഉപയോഗിച്ചു.

കൃത്യമായ പരിഹാരം

നിലവിലുള്ള സെർച്ച് റൂട്ടീനുള്ളിൽ തന്നെ മൂന്ന് ചെറിയ മാറ്റങ്ങളാണ് ഈ പരിഹാരത്തിനായി വരുത്തിയത്:

  • ഏതൊരു ഇൻകമിംഗ് സെർച്ച് ടേമിനും (search term) 48 ക്യാരക്ടറുകൾ എന്ന കർശനമായ പരിധി നിശ്ചയിച്ചു.
  • % വൈൽഡ്കാർഡുകൾ (wildcards) ചേർക്കുന്നതിന് മുമ്പ് ഇൻപുട്ട് സ്ട്രിംഗിനെ ആ നീളത്തിലേക്ക് മുറിച്ചു (slice).
  • പുതിയ ലൈബ്രറികൾ ഒന്നും ചേർക്കാതെ തന്നെ സെർച്ച് കൃത്യത നിലനിർത്തിക്കൊണ്ട് ക്വറിയുടെ ബാക്കി ഭാഗങ്ങൾ മാറ്റമില്ലാതെ വിട്ടു.

ഈ ക്രമീകരണം ക്വറി SQLite-ൽ എത്തുന്നതിന് മുമ്പ് തന്നെ നടക്കുന്നത് കൊണ്ട്, അവസാന പാറ്റേൺ ഒരിക്കലും 50-ബൈറ്റ് പരിധിയിൽ exceed ചെയ്യുന്നില്ല, അതിനാൽ Worker ഇനി ക്രാഷ് ആകില്ല. അധിക ഡിപെൻഡൻസികൾ (dependencies) ഒന്നും ചേർക്കാത്തതിനാൽ കോഡ്ബേസ് ഭാരം കുറഞ്ഞതായാണ് നിലനിൽക്കുന്നത്.

എന്തുകൊണ്ട് ഇത് പ്രധാനമാണ്

ലോ-ലാറ്റൻസി (low-latency) ആവശ്യങ്ങൾക്കായി എഡ്ജ്-ഹോസ്റ്റഡ് ഡാറ്റാബേസുകൾ ആകർഷകമാണ്, എന്നാൽ അവ ഓൺ-പ്രെമിസ് പതിപ്പുകളിലുള്ള അതേ നിയന്ത്രണങ്ങൾ നേരിടുന്നുണ്ട്. ഒരു റൺടൈം അൺകാറ്റ് എക്സെപ്ഷനുകളെ ഗുരുതരമായ പിശകായി കണക്കാക്കുമ്പോൾ, അറിയപ്പെടാത്ത കംപൈൽ-ടൈം പരിധികൾ പ്രൊഡക്ഷനെ തടസ്സപ്പെടുത്തുന്ന ബഗ്ഗുകളായി മാറാം. ഇവിടെ, നീളമുള്ള സബ്ജക്ട് ലൈൻ ടൈപ്പ് ചെയ്യുന്ന ഏതൊരു ഉപയോക്താവിനും AI ഇമെയിൽ അസിസ്റ്റന്റ് പ്രവർത്തിക്കാത്ത അവസ്ഥയുണ്ടായി—ഇത് ഉപയോക്താവിന്റെ അനുഭവത്തെയും (user experience) സെർവ്ലെസ് പ്ലാറ്റ്‌ഫോമുകളുടെ വിശ്വാസ്യതയെയും നേരിട്ട് ബാധിച്ചു.

മറ്റെന്തൊക്കെ ചെയ്യാമായിരുന്നു

പരിഹാരം ലളിതമാണെങ്കിലും, ഒരു പരിശോധനാ ഘട്ടം (validation step) വിട്ടുപോയത് ഇത് വ്യക്തമാക്കുന്നു. SQL സ്ട്രിംഗ് നിർമ്മിക്കുന്നതിന് മുമ്പ് പാറ്റേൺ നീളം പരിശോധിക്കുന്ന ഇൻപുട്ട് സാനിറ്റൈസേഷൻ (input sanitization) പ്രൊഡക്ഷനിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ ഡെവലപ്‌മെന്റ് ഘട്ടത്തിൽ ഈ പ്രശ്നം കണ്ടെത്തുമായിരുന്നു.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

എഡ്ജ് റൺടൈമുകളിൽ SQLite ഉപയോഗിക്കുന്ന ഡെവലപ്പർമാർ, പാറ്റേൺ മാച്ചിംഗ് ഉൾപ്പെടുന്ന എല്ലാ ക്വറികളും പരിശോധിക്കണം, പ്രത്യേകിച്ച് വൈൽഡ്കാർഡുകളോ എസ്കേപ്പ് ക്യാരക്ടറുകളോ (escape characters) ചേർക്കുന്നവ. SQLite പരാജയപ്പെട്ട കൃത്യമായ വരി Sentry കണ്ടെത്തിയിട്ടുണ്ട്. എഡ്ജ് കമ്പ്യൂട്ടിംഗ് വ്യാപകമാകുന്നതോടെ, ഒളിഞ്ഞിരിക്കുന്ന പ്ലാറ്റ്‌ഫോം പരിധികൾ കൂടുതൽ തവണ പുറത്തുവരും. അതിനാൽ ഡോക്യുമെന്റേഷനിലെ നിയന്ത്രണങ്ങൾക്കനുസരിച്ച് ഇൻപുട്ടുകൾ പരിശോധിക്കുന്ന ശീലം വളർത്തിയെടുക്കുന്നത് ഗുണകരമാകും.

ചുരുക്കത്തിൽ: SQLite LIKE പാറ്റേണുകളിലെ 50-ബൈറ്റ് പരിധി Cloudflare Workers-നെ ക്രാഷ് ചെയ്യിപ്പിച്ചേക്കാം, എന്നാൽ സെർച്ച് ടേമുകൾ 48 ക്യാരക്ടറുകളായി പരിമിതപ്പെടുത്തുന്നതിലൂടെ അധിക ഭാരമില്ലാതെ തന്നെ ഈ പ്രശ്നം പരിഹരിക്കാം—ചെറിയൊരു വാലിഡേഷൻ സ്റ്റെപ്പ് എഡ്ജ് സർവീസുകളെ സുസ്ഥിരമായി നിലനിർത്താൻ സഹായിക്കുമെന്നതിന് തെളിവാണിത്.