یک محدودیت پنهان ۵۰ بایتی در الگوهای LIKE در SQLite باعث از کار افتادن (crash) Cloudflare Workers شد؛ این اتفاق زمانی رخ داد که پروژه Agentic Inbox سعی داشت موضوعات طولانی ایمیل را جستجو کند. کوتاه کردن رشته‌های جستجو به ۴۸ کاراکتر، این خطاها را متوقف کرد.

آنچه باعث خرابی زمان‌اجرای لبه (edge runtime) شد

Agentic Inbox هر صندوق پستی را درون یک Cloudflare Durable Object اجرا می‌کند و از یک پایگاه داده SQLite داخلی برای ذخیره‌سازی استفاده می‌نماید. عامل مبتنی بر هوش مصنوعی، الگوی جستجو را به صورت %search_term% می‌سازد. SQLite یک سقف سخت‌گیرانه ۵۰ بایتی برای طول کل الگوی LIKE اعمال می‌کند. زمانی که کاربر موضوعی طولانی‌تر از ۴۸ کاراکتر وارد می‌کرد، علامت‌های % در اطراف آن، طول الگو را از آن سقف فراتر می‌برد. SQLite یک خطای زمان‌اجرای مدیریت‌نشده (unhandled runtime error) صادر می‌کرد که محیط محدود Worker آن را به عنوان خطای بحرانی (fatal) تلقی می‌کرد. کل اسکریپت متوقف می‌شد و این امر باعث می‌شد صندوق پستی غیرقابل استفاده و عامل هوش مصنوعی از کار بیفتد.

چگونگی کشف باگ

Sentry استثناهای (exceptions) مدیریت‌نشده از Workers را ثبت کرد. هنگامی که کرش رخ داد، Sentry دقیقاً خطی را که SQLite در آن خطا صادر کرده بود، ثبت کرد. قابلیت “Seer AI” آن، ردپای پشته (stack trace) را تجزیه کرد، ساختار الگوی LIKE را برجسته نمود و طول الگو را به عنوان عامل اصلی مشکل پیشنهاد داد. بررسی سریع مستندات زمانِ کامپایل (compile-time) SQLite، محدودیت ۵۰ بایتی را تأیید کرد و تیم از Gemini برای تأیید این محدودیت و محاسبه حداکثر طول ایمن برای ورودی کاربر استفاده کرد.

اصلاح دقیق

این راهکار شامل سه تغییر کوچک بود که همگی در داخل روتین جستجوی موجود انجام شد:

  • اعمال یک سقف سخت‌گیرانه ۴۸ کاراکتری برای هر عبارت جستجوی ورودی.
  • برش دادن رشته ورودی به همان طول، پیش از الحاق کاراکترهای Wildcard %.
  • بدون تغییر باقی گذاشتن سایر بخش‌های پرس‌وجو (query) برای حفظ دقت جستجو، بدون نیاز به افزودن کتابخانه‌های جدید.

از آنجایی که این تنظیمات پیش از رسیدن پرس‌وجو به SQLite انجام می‌شود، الگوی نهایی هرگز از آستانه ۵۰ بایتی فراتر نمی‌رود و Worker دیگر کرش نمی‌کند. هیچ وابستگی (dependency) اضافی اضافه نشد، بنابراین کد همچنان سبک باقی می‌ماند.

چرا این موضوع اهمیت دارد

پایگاه‌های داده میزبانی‌شده در لبه (Edge-hosted) برای موارد استفاده با تأخیر کم (low-latency) جذاب هستند، اما همان محدودیت‌های نسخه‌های محلی (on-premises) را نیز دارند. یک محدودیت مبهم در زمان کامپایل می‌تواند زمانی که یک زمان‌اجرا (runtime) هر استثنای مدیریت‌نشده را به عنوان خطای بحرانی تلقی می‌کند، به باگی تبدیل شود که مانع از فعالیت در محیط عملیاتی (production) می‌شود. در اینجا، این کرش باعث شد دستیار ایمیل مبتنی بر هوش مصنوعی برای هر کاربری که موضوع طولانی تایپ می‌کرد، از کار بیفتد؛ این موضوع ضربه‌ای مستقیم به تجربه کاربری و وعده قابلیت اطمینان پلتفرم‌های بدون سرور (serverless) بود.

چه کارهای متفاوتی می‌توانست انجام شود

اصلاح انجام‌شده ساده است، اما نشان‌دهنده یک مرحله اعتبارسنجی فراموش‌شده است. پاک‌سازی ورودی (Input sanitization) که طول الگو را پیش از ساخت رشته SQL بررسی کند، می‌توانست این مشکل را در مرحله توسعه شناسایی کند، نه در محیط عملیاتی.

آنچه باید در آینده مراقب آن بود

توسعه‌دهندگانی که SQLite را در زمان‌اجراهای لبه مستقر می‌کنند، باید تمام ساختارهای پرس‌وجو را که شامل تطبیق الگو (pattern matching) هستند، به‌ویژه مواردی که کاراکترهای Wildcard یا کاراکترهای فرار (escape characters) را اضافه می‌کنند، بازبینی کنند. Sentry دقیقاً خطی را که SQLite در آن شکست خورد، ثبت کرد. با گسترش محاسبات لبه (edge computing)، محدودیت‌های پنهان پلتفرم‌ها بیشتر خود را نشان خواهند داد و عادت به اعتبارسنجی ورودی‌ها بر اساس محدودیت‌های مستند شده، بسیار ارزشمند خواهد بود.

نکته کلیدی: یک سقف ۵۰ بایتی در الگوهای LIKE در SQLite می‌تواند باعث از کار افتادن Cloudflare Workers شود، اما کوتاه کردن عبارت‌های جستجو به ۴۸ کاراکتر، بدون هیچ بار اضافی، این خطا را از بین می‌برد؛ این مدرکی است بر اینکه یک مرحله اعتبارسنجی کوچک می‌تواند پایداری سرویس‌های لبه را حفظ کند.