SQLite के LIKE patterns पर एक छिपी हुई 50-byte की सीमा के कारण Cloudflare Workers क्रैश हो गए जब Agentic Inbox प्रोजेक्ट ने लंबे ईमेल सब्जेक्ट्स को सर्च करने की कोशिश की, और सर्च स्ट्रिंग्स को 48 कैरेक्टर्स तक ट्रिम करने से ये फेलियर रुक गए।

क्या चीज़ edge runtime को खराब कर रही थी

Agentic Inbox प्रत्येक मेलबॉक्स को Cloudflare Durable Object के अंदर चलाता है, और स्टोरेज के लिए एक एम्बेडेड SQLite डेटाबेस का उपयोग करता है। AI-संचालित एजेंट %search_term% के रूप में एक सर्च पैटर्न बनाता है। SQLite, LIKE पैटर्न की कुल लंबाई पर 50-byte की एक सख्त सीमा (ceiling) लागू करता है। जब किसी यूजर ने 48 कैरेक्टर्स से अधिक लंबा सब्जेक्ट डाला, तो आसपास के % संकेतों ने पैटर्न को उस सीमा से आगे धकेल दिया। SQLite ने एक unhandled runtime error दिया, जिसे सीमित Worker वातावरण ने fatal (घातक) माना। पूरा स्क्रिप्ट समाप्त हो गया, जिससे इनबॉक्स अनुपयोगी हो गया और AI एजेंट खराब हो गया।

बग का पता कैसे चला

Sentry ने Workers से uncaught exceptions को लॉग किया। जब क्रैश हुआ, तो Sentry ने उस सटीक लाइन को रिकॉर्ड किया जहाँ SQLite ने एरर दिया था। इसके “Seer AI” फीचर ने stack trace को पार्स किया, LIKE पैटर्न के निर्माण को हाईलाइट किया, और पैटर्न की लंबाई को ही मुख्य कारण (culprit) के रूप में सुझाया। SQLite के compile-time डॉक्यूमेंटेशन पर एक त्वरित नज़र ने 50-byte की पाबंदी की पुष्टि की, और टीम ने इस सीमा को सत्यापित करने और यूजर इनपुट के लिए एक सुरक्षित अधिकतम लंबाई की गणना करने के लिए Gemini का उपयोग किया।

सटीक समाधान

समाधान के लिए मौजूदा सर्च रूटीन के भीतर तीन छोटे बदलावों की आवश्यकता थी:

  • किसी भी आने वाले सर्च टर्म पर 48 कैरेक्टर्स की सख्त सीमा (hard cap) लगाना।
  • % वाइल्डकार्ड्स को जोड़ने से पहले इनपुट स्ट्रिंग को उस लंबाई तक स्लाइस करना।
  • बाकी क्वेरी को अपरिवर्तित रखना, ताकि नई लाइब्रेरी जोड़े बिना सर्च की सटीकता बनी रहे।

क्योंकि यह एडजस्टमेंट क्वेरी के SQLite तक पहुँचने से पहले ही हो जाता है, इसलिए अंतिम पैटर्न कभी भी 50-byte की सीमा को पार नहीं करता है, और Worker अब क्रैश नहीं होता है। कोई अतिरिक्त डिपेंडेंसी नहीं जोड़ी गई, इसलिए कोडबेस हल्का (lightweight) बना रहता है।

यह क्यों महत्वपूर्ण है

लो-लेटेंसी (low-latency) उपयोग के मामलों के लिए edge-hosted डेटाबेस आकर्षक होते हैं, लेकिन वे ऑन-प्रिमाइसेस वर्ज़न की तरह ही समान बाधाओं को भी अपनाते हैं। एक अस्पष्ट compile-time सीमा प्रोडक्शन को रोकने वाला बग बन सकती है जब कोई रनटाइम किसी भी uncaught exception को fatal मानता है। यहाँ, क्रैश ने उस AI-संचालित ईमेल असिस्टेंट को काम करने से रोक दिया जो किसी भी ऐसे यूजर के लिए काम करता जिसने लंबा सब्जेक्ट टाइप किया था—यह यूजर एक्सपीरियंस और सर्वरलेस प्लेटफॉर्म के विश्वसनीयता के वादे पर सीधा