ข้อจำกัด 50 ไบต์ที่ซ่อนอยู่ในรูปแบบ LIKE ของ SQLite ทำให้ Cloudflare Workers เกิดการแครชเมื่อโปรเจกต์ Agentic Inbox พยายามค้นหาหัวข้ออีเมลที่มีความยาว และการตัดข้อความค้นหาให้เหลือเพียง 48 ตัวอักษรช่วยหยุดปัญหาดังกล่าวได้

สิ่งที่ทำให้ edge runtime พัง

Agentic Inbox รันแต่ละกล่องจดหมายภายใน Cloudflare Durable Object โดยใช้ฐานข้อมูล SQLite แบบฝัง (embedded) สำหรับการจัดเก็บข้อมูล เอเจนต์ที่ขับเคลื่อนด้วย AI จะสร้างรูปแบบการค้นหาเป็น %search_term% โดย SQLite มีการบังคับใช้เพดานจำกัดที่ 50 ไบต์สำหรับความยาวรวมของรูปแบบ LIKE เมื่อผู้ใช้ป้อนหัวข้อที่ยาวกว่า 48 ตัวอักษร เครื่องหมาย % ที่ล้อมรอบจะทำให้รูปแบบนั้นเกินเพดานที่กำหนดไว้ SQLite จึงส่งข้อผิดพลาด runtime ที่ไม่ได้รับการจัดการ (unhandled runtime error) ซึ่งสภาพแวดล้อมของ Worker ที่มีข้อจำกัดจะถือว่าเป็นข้อผิดพลาดร้ายแรง (fatal error) ส่งผลให้สคริปต์ทั้งหมดหยุดทำงาน ทำให้กล่องจดหมายใช้งานไม่ได้และเอเจนต์ AI เสียหาย

วิธีการค้นพบข้อผิดพลาด

Sentry ได้บันทึก exception ที่ไม่ได้รับการดักจับ (uncaught exceptions) จาก Workers เมื่อเกิดการแครช Sentry ได้บันทึกบรรทัดที่แน่นอนที่ SQLite แจ้งข้อผิดพลาด ฟีเจอร์ “Seer AI” ของ Sentry ได้วิเคราะห์ stack trace ระบุตำแหน่งการสร้างรูปแบบ LIKE และเสนอว่าความยาวของรูปแบบคือสาเหตุ เมื่อตรวจสอบเอกสารประกอบการคอมไพล์ (compile-time documentation) ของ SQLite อย่างรวดเร็ว ก็พบว่ามีการจำกัดไว้ที่ 50 ไบต์จริง และทีมงานได้ใช้ Gemini เพื่อตรวจสอบขีดจำกัดนี้และคำนวณความยาวสูงสุดที่ปลอดภัยสำหรับข้อมูลนำเข้าของผู้ใช้

การแก้ไขอย่างตรงจุด

การแก้ไขต้องใช้การเปลี่ยนแปลงเล็กๆ เพียงสามจุด ภายในรูทีนการค้นหาเดิม:

  • กำหนดเพดานสูงสุดที่ 48 ตัวอักษรสำหรับข้อความค้นหาที่รับเข้ามา
  • ตัดข้อความนำเข้าให้มีความยาวตามนั้นก่อนที่จะต่อด้วย wildcard %
  • ปล่อยส่วนที่เหลือของ query ไว้ตามเดิม เพื่อรักษาความแม่นยำในการค้นหาโดยไม่ต้องเพิ่ม library ใหม่

เนื่องจากการปรับเปลี่ยนนี้เกิดขึ้นก่อนที่ query จะส่งไปถึง SQLite รูปแบบสุดท้ายจึงไม่เกินเกณฑ์ 50 ไบต์ และ Worker ก็ไม่เกิดการแครชอีกต่อไป ไม่มีการเพิ่ม dependency อื่นๆ ทำให้ codebase ยังคงมีน้ำหนักเบา

ทำไมเรื่องนี้ถึงสำคัญ

ฐานข้อมูลที่โฮสต์บน edge นั้นน่าดึงดูดสำหรับกรณีการใช้งานที่ต้องการความหน่วงต่ำ (low-latency) แต่ก็ต้องรับข้อจำกัดแบบเดียวกับเวอร์ชัน on-premises ข้อจำกัดในขั้นตอน compile-time ที่ไม่ชัดเจนสามารถกลายเป็นบั๊กที่ขัดขวางการทำงานในระบบ production ได้ เมื่อ runtime มองว่า exception ใดๆ ที่ไม่ได้รับการดักจับเป็นข้อผิดพลาดร้ายแรง ในกรณีนี้ การแครชทำให้ผู้ช่วยอีเมลพลัง AI ไม่สามารถทำงานได้สำหรับผู้ใช้ทุกคนที่พิมพ์หัวข้ออีเมลยาวๆ ซึ่งส่งผลกระทบโดยตรงต่อประสบการณ์ผู้ใช้และความน่าเชื่อถือของแพลตฟอร์ม serverless

สิ่งที่สามารถทำต่างออกไปได้

การแก้ไขนั้นตรงไปตรงมา แต่ก็ชี้ให้เห็นถึงขั้นตอนการตรวจสอบ (validation) ที่ขาดหายไป การทำ input sanitization เพื่อตรวจสอบความยาวของรูปแบบก่อนที่จะสร้าง SQL string จะช่วยให้ตรวจพบปัญหานี้ได้ตั้งแต่ช่วงการพัฒนา แทนที่จะเป็นในระบบ production

สิ่งที่ควรเฝ้าระวังต่อไป

นักพัฒนาที่ใช้งาน SQLite บน edge runtimes ควรตรวจสอบการสร้าง query ทั้งหมดที่มีการจับคู่รูปแบบ (pattern matching) โดยเฉพาะอย่างยิ่งการเพิ่ม wildcard หรือ escape characters Sentry สามารถระบุบรรทัดที่ SQLite ทำงานล้มเหลวได้อย่างแม่นยำ เมื่อ edge computing ได้รับความนิยมมากขึ้น ข้อจำกัดที่ซ่อนอยู่ของแพลตฟอร์มจะปรากฏให้เห็นบ่อยขึ้น ดังนั้นการสร้างนิสัยในการตรวจสอบข้อมูลนำเข้าเทียบกับข้อจำกัดที่มีการระบุไว้ในเอกสารจึงเป็นเรื่องที่คุ้มค่า

บทสรุป: เพดาน 50 ไบต์ในรูปแบบ LIKE ของ SQLite สามารถทำให้ Cloudflare Workers แครชได้ แต่การตัดข้อความค้นหาให้เหลือ 48 ตัวอักษรช่วยกำจัดข้อผิดพลาดนี้ได้โดยไม่ต้องมีภาระส่วนเกินเพิ่มเติม ซึ่งเป็นข้อพิสูจน์ว่าขั้นตอนการตรวจสอบเพียงเล็กน้อยก็สามารถรักษาความเสถียรของบริการบน edge ได้