SQLite کے LIKE patterns پر 50-بائٹ کی ایک پوشیدہ حد کی وجہ سے Cloudflare Workers کریش ہو گئے جب Agentic Inbox پروجیکٹ نے طویل ای میل سبجیکٹس تلاش کرنے کی کوشش کی، اور سرچ اسٹرنگز کو 48 کریکٹرز تک محدود کرنے سے یہ ناکامیاں رک گئیں۔

کس چیز نے edge runtime کو خراب کیا

Agentic Inbox ہر میل باکس کو Cloudflare Durable Object کے اندر چلاتا ہے، اور اسٹوریج کے لیے ایک ایمبیڈڈ SQLite ڈیٹا بیس استعمال کرتا ہے۔ AI پر مبنی ایجنٹ سرچ پیٹرن کو %search_term% کے طور پر بناتا ہے۔ SQLite، LIKE pattern کی کل لمبائی پر 50-بائٹ کی سخت حد (ceiling) نافذ کرتا ہے۔ جب کسی صارف نے 48 کریکٹرز سے زیادہ طویل سبجیکٹ درج کیا، تو ارد گرد موجود % کے نشانات نے پیٹرن کو اس حد سے آگے دھکیل دیا۔ SQLite نے ایک unhandled runtime error پیدا کی، جسے محدود Worker ماحول نے سنگین (fatal) سمجھا۔ پورا اسکرپٹ ختم ہو گیا، جس سے ان باکس ناقابل استعمال ہو گیا اور AI ایجنٹ بھی کام کرنا چھوڑ گیا۔

بگ کا پتہ کیسے چلا

Sentry نے Workers سے ہونے والے uncaught exceptions کو لاگ کیا۔ جب کریش ہوا، تو Sentry نے اس درست لائن کو ریکارڈ کیا جہاں SQLite نے ایرر پیدا کیا۔ اس کے "Seer AI" فیچر نے stack trace کا تجزیہ کیا، LIKE pattern کی بناوٹ کو نمایاں کیا، اور پیٹرن کی لمبائی کو اس کی وجہ (culprit) کے طور پر تجویز کیا۔ SQLite کی compile-time دستاویزات پر ایک نظر ڈالنے سے 50-بائٹ کی پابندی کی تصدیق ہو گئی، اور ٹیم نے Gemini کا استعمال کرتے ہوئے اس حد کی تصدیق کی اور صارف کے ان پٹ کے لیے ایک محفوظ زیادہ سے زیادہ لمبائی کا حساب لگایا۔

بگ کا درستہ حل

اس مسئلے کے حل کے لیے تین معمولی تبدیلیاں درکار تھیں، جو کہ موجودہ سرچ روٹین کے اندر ہی تھیں:

  • کسی بھی آنے والی سرچ ٹرم پر 48 کریکٹرز کی سخت حد مقرر کرنا۔
  • % وائلڈ کارڈز (wildcards) کو جوڑنے سے پہلے ان پٹ اسٹرنگ کو اس لمبائی تک کاٹنا (slice)۔
  • باقی کوئری کو غیر تبدیل شدہ چھوڑنا، تاکہ نئی لائبریریز شامل کیے بغیر سرچ کی درستگی برقرار رہے۔

چونکہ یہ ایڈجسٹمنٹ کوئری کے SQLite تک پہنچنے سے پہلے ہی ہو جاتی ہے، اس لیے حتمی پیٹرن کبھی بھی 50-بائٹ کی حد سے تجاوز نہیں کرتا، اور Worker اب کریش نہیں ہوتا۔ کوئی اضافی ڈیپینڈنسیز (dependencies) شامل نہیں کی گئیں، اس لیے کوڈ بیس ہلکا پھلکا (lightweight) رہتا ہے۔

یہ کیوں اہم ہے

کم لیٹنسی (low-latency) والے استعمال کے کیسز کے لیے edge-hosted ڈیٹا بیس پرکشش ہوتے ہیں، لیکن ان میں وہی پابندیاں ہوتی ہیں جو on-premises ورژنز میں ہوتی ہیں۔ ایک مبہم compile-time حد پروڈکشن کو روکنے والا بگ بن سکتی ہے جب کوئی runtime کسی بھی uncaught exception کو سنگین (fatal) قرار دے دے۔ یہاں، کریش نے AI سے چلنے والے ای میل اسسٹنٹ کو ان تمام صارفین کے لیے کام کرنے سے روک دیا جنہوں نے طویل سبجیکٹ لائن لکھی تھی—جو کہ صارف کے تجربے (user experience) اور سرور لیس پلیٹ فارمز کے بھروسے پر براہ راست ضرب ہے۔

کیا مختلف کیا جا سکتا تھا

حل سادہ ہے، لیکن یہ ایک نظر انداز شدہ ویلیڈیشن مرحلے کی نشاندہی کرتا ہے۔ SQL اسٹرنگ بنانے سے پہلے پیٹرن کی لمبائی چیک کرنے والا ان پٹ سینیٹائزیشن (input sanitization) اس مسئلے کو پروڈکشن کے بجائے ڈویلپمنٹ کے دوران ہی پکڑ لیتا۔

آگے کس چیز کا خیال رکھیں

edge runtimes پر SQLite استعمال کرنے والے ڈویلپرز کو ان تمام کوئری کنسٹرکشنز کا آڈٹ کرنا چاہیے جن میں پیٹرن میچنگ شامل ہو، خاص طور پر وہ جن میں وائلڈ کارڈز یا ایسکیپ کریکٹرز (escape characters) شامل کیے جاتے ہیں۔ Sentry نے اس درست لائن کو پکڑا جہاں SQLite ناکام ہوا۔ جیسے جیسے edge کمپیوٹنگ مقبول ہو رہی ہے، پوشیدہ پلیٹ فارم کی حدود زیادہ اکثر سامنے آئیں گی، اور دستاویز شدہ پابندیوں کے مطابق ان پٹ کی تصدیق کرنے کی عادت فائدہ مند ثابت ہوگی۔

حاصلِ کلام: SQLite LIKE patterns پر 50-بائٹ کی حد Cloudflare Workers کو کریش کر سکتی ہے، لیکن سرچ ٹرمز کو 48 کریکٹرز تک محدود کرنے سے بغیر کسی اضافی بوجھ کے خرابی ختم ہو جاتی ہے—یہ اس بات کا ثبوت ہے کہ ایک چھوٹا سا ویلیڈیشن مرحلہ edge سروسز کو مستحکم رکھ سکتا ہے۔