SQLite ના LIKE પેટર્ન પર રહેલી 50-બાઇટની છુપી મર્યાદાને કારણે Cloudflare Workers ક્રેશ થઈ ગયા હતા જ્યારે Agentic Inbox પ્રોજેક્ટ લાંબા ઇમેઇલ વિષયો (subjects) શોધવાનો પ્રયાસ કરી રહ્યો હતો, અને સર્ચ સ્ટ્રિંગ્સને 48 અક્ષરો સુધી ટ્રીમ કરવાથી આ સમસ્યાઓ અટકી ગઈ.

એજ રનટાઇમને (edge runtime) શેણે તોડ્યું

Agentic Inbox દરેક મેઇલબોક્સને Cloudflare Durable Object ની અંદર ચલાવે છે, જેમાં સ્ટોરેજ માટે એમ્બેડેડ SQLite ડેટાબેઝનો ઉપયોગ થાય છે. AI-સંચાલિત એજન્ટ %search_term% તરીકે સર્ચ પેટર્ન બનાવે છે. SQLite, LIKE પેટર્નની કુલ લંબાઈ પર 50-બાઇટની સખત મર્યાદા (ceiling) લાદે છે. જ્યારે વપરાશકર્તાએ 48 અક્ષરોથી વધુ લાંબો વિષય દાખલ કર્યો, ત્યારે તેની આસપાસના % ચિહ્નોએ પેટર્નને તે મર્યાદાથી આગળ ધકેલી દીધી. SQLite એ એક અનહેન્ડલ રનટાઇમ એરર (unhandled runtime error) ફેંકી, જેને મર્યાદિત Worker એન્વાયરન્મેન્ટે ગંભીર (fatal) ગણ્યું. આખું સ્ક્રિપ્ટ બંધ થઈ ગયું, જેના કારણે ઇનબોક્સ બિનઉપયોગી બની ગયું અને AI એજન્ટ બગડી ગયો.

બગ કેવી રીતે શોધવામાં આવ્યો

Sentry એ Workers માંથી અનકેપ્ટ એક્સેપ્શન્સ (uncaught exceptions) લોગ કર્યા. જ્યારે ક્રેશ જોવા મળ્યો, ત્યારે Sentry એ ચોક્કસ લાઇન રેકોર્ડ કરી જ્યાં SQLite એ એરર આપી હતી. તેની “Seer AI” ફીચરે સ્ટેક ટ્રેસ (stack trace) નું વિશ્લેષણ કર્યું, LIKE પેટર્ન બનાવવાની પ્રક્રિયાને હાઇલાઇટ કરી અને પેટર્નની લંબાઈને મુખ્ય કારણ તરીકે સૂચવી. SQLite ના કમ્પાઇલ-ટાઇમ ડોક્યુમેન્ટેશન પર નજર નાખતા 50-બાઇટની મર્યાદાની પુષ્ટિ થઈ, અને ટીમે Gemini નો ઉપયોગ કરીને આ મર્યાદાની ચકાસણી કરી અને યુઝર ઇનપુટ માટે સુરક્ષિત મહત્તમ લંબાઈની ગણતરી કરી.

સચોટ સુધારો (The surgical fix)

આ સમસ્યાના નિવારણ માટે હાલના સર્ચ રૂટિનમાં ત્રણ નાના ફેરફારો કરવા પડ્યા:

  • કોઈપણ આવતા સર્ચ ટર્મ પર 48 અક્ષરોની સખત મર્યાદા લાદવી.
  • % વાઇલડકાર્ડ્સ જોડતા પહેલા ઇનપુટ સ્ટ્રિંગને તે લંબાઈ સુધી કાપી નાખવી (slice).
  • નવી લાઇબ્રેરીઓ ઉમેર્યા વગર સર્ચની ચોકસાઈ જાળવી રાખીને બાકીની ક્વેરીને યથાવત રાખવી.

કારણ કે ક્વેરી SQLite સુધી પહોંચે તે પહેલાં જ આ ફેરફાર થઈ જાય છે, તેથી અંતિમ પેટર્ન ક્યારેય 50-બાઇટની મર્યાદા ઓળંગતી નથી, અને Worker હવે ક્રેશ થતું નથી. કોઈ વધારાની ડિપેન્ડન્સીઝ ઉમેરવામાં આવી નથી, તેથી કોડબેઝ હળવું (lightweight) રહે છે.

તે શા માટે મહત્વનું છે

લો-લેટન્સી (low-latency) ઉપયોગ માટે એજ-હોસ્ટેડ ડેટાબેઝ આકર્ષક છે, પરંતુ તેઓ ઓન-પ્રેમિસ વર્ઝન જેવી જ મર્યાદાઓ ધરાવે છે. જ્યારે રનટાઇમ કોઈપણ અનકેપ્ટ એક્સેપ્શનને ગંભીર (fatal) ગણે છે, ત્યારે એક અસ્પષ્ટ કમ્પાઇલ-ટાઇમ મર્યાદા પ્રોડક્શનને રોકતો બગ બની શકે છે. અહીં, ક્રેશને કારણે એવા તમામ વપરાશકર્તાઓ માટે AI-સંચાલિત ઇમેઇલ આસિસ્ટન્ટ કામ કરવાનું બંધ કરી દીધું જેઓ લાંબી સબ્જેક્ટ લાઇન ટાઇપ કરતા હતા—જે યુઝર એક્સપિરિયન્સ અને સર્વરલેસ પ્લેટફોર્મ્સના વિશ્વસનીયતાના વચનને સીધી અસર કરે છે.

અલગ રીતે શું કરી શકાયું હોત

સુધારો સરળ છે, પરંતુ તે ચૂકી ગયેલા વેરિફિકેશન સ્ટેપને રેખાંકિત કરે છે. SQL સ્ટ્રિંગ બનાવતા પહેલા પેટર્નની લંબાઈ તપાસતું ઇનપુટ સેનિટાઇઝેશન (input sanitization) પ્રોડક્શનને બદલે ડેવલપમેન્ટ દરમિયાન જ આ સમસ્યાને પકડી લેત.

હવે શેના પર ધ્યાન આપવું

એજ રનટાઇમ પર SQLite તૈનાત કરતા ડેવલપર્સે પેટર્ન મેચિંગ ધરાવતી તમામ ક્વેરી કન્સ્ટ્રક્શનનું ઓડિટ કરવું જોઈએ, ખાસ કરીને જે વાઇલડકાર્ડ્સ અથવા એસ્કેપ કેરેક્ટર્સ ઉમેરે છે. Sentry એ ચોક્કસ લાઇન કેપ્ચર કરી હતી જ્યાં SQLite નિષ્ફળ ગયું હતું. જેમ જેમ એજ કમ્પ્યુટિંગ લોકપ્રિય બની રહ્યું છે, તેમ છુપી પ્લેટફોર્મ મર્યાદાઓ વધુ વારંવાર સામે આવશે, અને દસ્તાવેજીકૃત મર્યાદાઓ સામે ઇનપુટને વેરિફાય કરવાની આદત ફાયદાકારક રહેશે.

સારાંશ: SQLite LIKE પેટર્ન પર 50-બાઇટની મર્યાદા Cloudflare Workers ને ક્રેશ કરી શકે છે, પરંતુ સર્ચ ટર્મ્સને 48 અક્ષરો સુધી ટ્રીમ કરવાથી કોઈપણ વધારાના બોજ વગર ખામી દૂર થાય છે—જે સાબિત કરે છે કે એક નાનું વેરિફિકેશન સ્ટેપ એજ સર્વિસીસને સ્થિર રાખી શકે છે.