SQLite च्या LIKE पॅटर्नवरील ५०-बाइटच्या (50-byte) एका गुप्त मर्यादेमुळे, जेव्हा Agentic Inbox प्रकल्पाने लांब ईमेल विषयांचा शोध घेण्याचा प्रयत्न केला, तेव्हा Cloudflare Workers क्रॅश झाले; आणि सर्च स्ट्रिंग्स ४८ कॅरेक्टर्सपर्यंत (48 characters) मर्यादित केल्यामुळे हे दोष थांबले.

एज रनटाइममध्ये (edge runtime) काय बिघडले

Agentic Inbox प्रत्येक मेलबॉक्स Cloudflare Durable Object मध्ये चालवते, ज्यामध्ये स्टोरेजसाठी एम्बेडेड SQLite डेटाबेस वापरला जातो. AI-चालित एजंट %search_term% या स्वरूपात सर्च पॅटर्न तयार करतो. SQLite, LIKE पॅटर्नच्या एकूण लांबीवर ५०-बाइटची (50-byte) कडक मर्यादा लागू करते. जेव्हा वापरकर्त्याने ४८ कॅरेक्टर्सपेक्षा जास्त लांबीचा विषय (subject) टाकला, तेव्हा बाजूला असलेल्या % चिन्हांमुळे पॅटर्नची लांबी त्या मर्यादेच्या पलीकडे गेली. SQLite ने एक अनहँडल्ड (unhandled) रनटाइम एरर दिली, ज्याला मर्यादित Worker एन्व्हायरनमेंटने 'फेटल' (fatal) मानले. यामुळे संपूर्ण स्क्रिप्ट थांबली, ज्यामुळे इनबॉक्स वापरण्याअयोग्य झाला आणि AI एजंटही निकामी झाला.

हा बग कसा शोधला गेला

Sentry ने Workers कडून येणारे अनकॉट एक्सेप्शन (uncaught exceptions) लॉग केले. जेव्हा क्रॅश झाला, तेव्हा Sentry ने SQLite ने एरर दर्शवलेली नेमकी ओळ रेकॉर्ड केली. त्याच्या “Seer AI” फीचरने स्टॅक ट्रेस (stack trace)चे विश्लेषण केले, LIKE पॅटर्नच्या रचनेवर प्रकाश टाकला आणि पॅटर्नची लांबी हीच या समस्येचे मूळ कारण असल्याचे सुचवले. SQLite च्या कंपाईल-टाइम (compile-time) डॉक्युमेंटेशनमधील एका झटक्यामुळे ५०-बाइटची ही मर्यादा असल्याचे स्पष्ट झाले, आणि टीमने ही मर्यादा तपासण्यासाठी आणि वापरकर्त्याच्या इनपुटसाठी सुरक्षित कमाल लांबी मोजण्यासाठी Gemini चा वापर केला.

अचूक उपाय (The surgical fix)

या समस्येचे निराकरण करण्यासाठी विद्यमान सर्च रूटीनमध्ये तीन लहान बदल करावे लागले:

  • कोणत्याही येणाऱ्या सर्च टर्मवर ४८ कॅरेक्टर्सची कडक मर्यादा लागू करणे.
  • % वाइल्डकार्ड्स जोडण्यापूर्वी इनपुट स्ट्रिंगला त्या लांबीपर्यंत कापून घेणे (slice).
  • नवीन लायब्ररी न जोडता सर्चची अचूकता कायम ठेवत उर्वरित क्वेरीमध्ये कोणताही बदल न करणे.

ही सुधारणा क्वेरी SQLite पर्यंत पोहोचण्यापूर्वीच होत असल्याने, अंतिम पॅटर्न कधीही ५०-बाइटच्या मर्यादेच्या पलीकडे जात नाही आणि Worker पुन्हा क्रॅश होत नाही. यामध्ये कोणतीही अतिरिक्त डिपेंडन्सीज (dependencies) जोडली गेली नाहीत, त्यामुळे कोडबेस हलका (lightweight) राहतो.

हे महत्त्वाचे का आहे

लो-लॅटन्सी (low-latency) वापरासाठी एज-होस्टेड (edge-hosted) डेटाबेस आकर्षक असतात, परंतु त्यांना ऑन-प्रिमाइसेस (on-premises) आवृत्त्यांप्रमाणेच समान मर्यादांचा सामना करावा लागतो. जेव्हा एखादा रनटाइम कोणत्याही अनकॉट एक्सेप्शनला 'फेटल' मानतो, तेव्हा कंपाईल-टाइममधील एक अस्पष्ट मर्यादा प्रोडक्शनमध्ये अडथळा आणणारा बग बनू शकते. येथे, क्रॅशमुळे लांब विषय लाइन टाइप करणाऱ्या कोणत्याही वापरकर्त्यासाठी AI-आधारित ईमेल असिस्टंट काम करणे थांबले—हे युजर एक्सपिरियन्स (user experience) आणि सर्व्हरलेस प्लॅटफॉर्मच्या विश्वासार्हतेच्या आश्वासनावर थेट परिणाम करणारे आहे.

वेगळ्या पद्धतीने काय करता आले असते

हा उपाय सोपा आहे, परंतु तो एका सुटलेल्या व्हॅलिडेशन स्टेपकडे (validation step) लक्ष वेधतो. SQL स्ट्रिंग तयार करण्यापूर्वी पॅटर्नची लांबी तपासणारे इनपुट सॅनिटायझेशन (input sanitization) असल्यास, ही समस्या प्रोडक्शनमध्ये येण्याऐवजी डेव्हलपमेंट दरम्यानच पकडली गेली असती.

पुढे कशाकडे लक्ष द्यावे

एज रनटाइमवर SQLite तैनात करणाऱ्या डेव्हलपर्सनी पॅटर्न मॅचिंगमध्ये गुंतलेल्या सर्व क्वेरी रचनांचे ऑडिट केले पाहिजे, विशेषतः ज्यामध्ये वाइल्डकार्ड्स किंवा एस्केप कॅरेक्टर्स (escape characters) जोडले जातात. Sentry ने SQLite जिथे फेल झाले ती नेमकी ओळ टिपली होती. जसजसे एज कम्प्युटिंग लोकप्रिय होत जाईल, तसतसे प्लॅटफॉर्ममधील गुप्त मर्यादा अधिक वारंवार समोर येतील, आणि डॉक्युमेंटेड मर्यादांच्या आधारे इनपुट व्हॅलिडेट करण्याची सवय फायदेशीर ठरेल.

निष्कर्ष (Takeaway): SQLite LIKE पॅटर्नवरील ५०-बाइटची मर्यादा Cloudflare Workers क्रॅश करू शकते, परंतु सर्च टर्म्स ४८ कॅरेक्टर्सपर्यंत मर्यादित केल्यामुळे कोणत्याही अतिरिक्त ओझ्याशिवाय ही त्रुटी दूर होते—हे सिद्ध करते की एक छोटी व्हॅलिडेशन स्टेप एज सेवा स्थिर ठेवू शकते.