تسبب حدّ مخفي قدره 50 بايت في أنماط LIKE الخاصة بـ SQLite في تعطل Cloudflare Workers عندما حاول مشروع Agentic Inbox البحث في عناوين رسائل بريد إلكتروني طويلة، وأدى تقليص سلاسل البحث إلى 48 حرفًا إلى إيقاف هذه الإخفاقات.

ما الذي تسبب في تعطل بيئة التشغيل الطرفية (edge runtime)

يعمل Agentic Inbox على تشغيل كل صندوق بريد داخل Cloudflare Durable Object، مستخدمًا قاعدة بيانات SQLite مدمجة للتخزين. يقوم الوكيل المدعوم بالذكاء الاصطناعي ببناء نمط بحث على هيئة %search_term%. تفرض SQLite حدًا صارمًا قدره 50 بايت على الطول الإجمالي لنمط LIKE. عندما أدخل مستخدم عنوانًا أطول من 48 حرفًا، دفعت علامات % المحيطة بالنمط لتتجاوز ذلك الحد. أطلقت SQLite خطأً غير معالج في وقت التشغيل، وهو ما تعاملت معه بيئة Worker المقيدة على أنه خطأ فادح. توقف النص البرمجي بالكامل، مما جعل صندوق البريد غير قابل للاستخدام وأدى إلى تعطل وكيل الذكاء الاصطناعي.

كيف تم اكتشاف الخطأ

قام Sentry بتسجيل الاستثناءات غير الملتقطة من الـ Workers. وعندما ظهر الانهيار، سجل Sentry السطر الدقيق الذي أطلقت فيه SQLite خطأً. قامت ميزة "Seer AI" الخاصة به بتحليل تتبع المكدس (stack trace)، وسلطت الضوء على بناء نمط LIKE واقترحت أن طول النمط هو السبب. أكدت نظرة سريعة على وثائق SQLite وقت التجميع (compile-time) وجود قيود الـ 50 بايت، واستخدم الفريق Gemini للتحقق من الحد وحساب أقصى طول آمن لمدخلات المستخدم.

الإصلاح الدقيق

تطلب الحل إجراء ثلاثة تغييرات صغيرة، جميعها داخل روتين البحث الحالي:

  • فرض حد أقصى صارم قدره 48 حرفًا على أي مصطلح بحث وارد.
  • تقطيع سلسلة الإدخال إلى ذلك الطول قبل دمج الرموز البديلة %.
  • ترك بقية الاستعلام دون تغيير، مما يحافظ على دقة البحث دون إضافة مكتبات جديدة.

نظرًا لأن التعديل يحدث قبل وصول الاستعلام إلى SQLite، فإن النمط النهائي لا يتجاوز أبدًا عتبة الـ 50 بايت، ولم يعد الـ Worker يتعطل. لم يتم إضافة أي تبعيات إضافية، لذا تظل قاعدة الكود خفيفة الوزن.

لماذا يهم هذا الأمر

تُعد قواعد البيانات المستضافة على الحافة (edge-hosted) جذابة لحالات الاستخدام ذات زمن الوصول المنخفض، لكنها ترث نفس القيود الموجودة في الإصدارات المحلية (on-premises). يمكن أن يتحول حد غامض وقت التجميع إلى خطأ يعيق الإنتاج عندما تتعامل بيئة التشغيل مع أي استثناء غير ملتقط على أنه خطأ فادح. هنا، أدى الانهيار إلى توقف مساعد البريد الإلكتروني المدعوم بالذكاء الاصطناعي عن العمل لأي مستخدم يكتب عنوانًا طويلاً—وهو ما يمثل ضربة مباشرة لتجربة المستخدم ووعد الموثوقية الذي تقدمه المنصات عديمة الخادم (serverless).

ما الذي كان يمكن فعله بشكل مختلف

الإصلاح مباشر، لكنه يسلط الضوء على خطوة تحقق مفقودة. إن تنقية المدخلات (Input sanitization) التي تتحقق من طول النمط قبل بناء سلسلة SQL كانت ستكشف المشكلة أثناء التطوير بدلاً من مرحلة الإنتاج.

ما يجب مراقبته لاحقًا

يجب على المطورين الذين ينشرون SQLite على بيئات التشغيل الطرفية (edge runtimes) مراجعة جميع عمليات بناء الاستعلامات التي تتضمن مطابقة الأنماط، خاصة تلك التي تضيف رموزًا بديلة (wildcards) أو رموز هروب (escape characters). لقد التقط Sentry السطر الدقيق الذي فشلت فيه SQLite. ومع اكتساب الحوسبة الطرفية (edge computing) زخمًا، ستظهر حدود المنصات المخفية بشكل متكرر، وسيكون الاعتياد على التحقق من المدخلات مقابل القيود الموثقة أمرًا مجزيًا.

الخلاصة: يمكن للحد الأقصى البالغ 50 بايت لأنماط LIKE في SQLite أن يتسبب في تعطل Cloudflare Workers، ولكن تقليص مصطلحات البحث إلى 48 حرفًا يقضي على هذا الخطأ دون أي أعباء إضافية—وهو دليل على أن خطوة تحقق صغيرة يمكن أن تحافظ على استقرار الخدمات الطرفية.