Had 50-bait yang tersembunyi pada corak LIKE SQLite menyebabkan Cloudflare Workers terhenti (crash) apabila projek Agentic Inbox cuba mencari subjek e-mel yang panjang, dan pemotongan rentetan carian kepada 48 aksara telah menghentikan kegagalan tersebut.

Apa yang merosakkan runtime edge

Agentic Inbox menjalankan setiap peti mel di dalam Cloudflare Durable Object, menggunakan pangkalan data SQLite terbenam untuk penyimpanan. Ejen dipacu AI membina corak carian sebagai %search_term%. SQLite mengenakan had siling keras 50-bait pada jumlah panjang corak LIKE. Apabila pengguna memasukkan subjek yang lebih panjang daripada 48 aksara, tanda % di sekelilingnya menolak corak tersebut melepasi siling tersebut. SQLite mencetuskan ralat runtime yang tidak dikendalikan, yang mana persekitaran Worker yang terhad menganggapnya sebagai ralat fatal. Keseluruhan skrip terhenti, menyebabkan peti mel tidak dapat digunakan dan ejen AI rosak.

Bagaimana pepijat tersebut ditemui

Sentry merekodkan pengecualian (exceptions) yang tidak ditangkap daripada Workers. Apabila kegagalan berlaku, Sentry merekodkan baris tepat di mana SQLite mencetuskan ralat. Ciri “Seer AI” miliknya menganalisis jejak timbunan (stack trace), menyerlahkan pembinaan corak LIKE, dan mencadangkan panjang corak sebagai punca masalah. Semakan pantas pada dokumentasi masa kompilasi (compile-time) SQLite mengesahkan sekatan 50-bait tersebut, dan pasukan menggunakan Gemini untuk mengesahkan had itu serta mengira panjang maksimum yang selamat untuk input pengguna.

Pembaikan tepat

Penyelesaian tersebut memerlukan tiga perubahan kecil, semuanya di dalam rutin carian sedia ada:

  • Mengenakan had keras 48 aksara pada mana-mana istilah carian yang masuk.
  • Memotong rentetan input kepada panjang tersebut sebelum menyambungkan (concatenating) simbol wildcard %.
  • Membiarkan baki pertanyaan (query) tidak berubah, bagi mengekalkan ketepatan carian tanpa menambah perpustakaan (library) baharu.

Oleh kerana pelarasan berlaku sebelum pertanyaan sampai ke SQLite, corak akhir tidak akan melebihi ambang 50-bait, dan Worker tidak lagi terhenti. Tiada kebergantungan (dependencies) tambahan ditambah, jadi kod asas kekal ringan.

Mengapa ia penting

Pangkalan data hos-edge menarik untuk kes penggunaan kependaman rendah (low-latency), tetapi ia mewarisi kekangan yang sama seperti versi on-premises. Had masa kompilasi yang kabur boleh menjadi pepijat yang menghalang pengeluaran (production-blocking) apabila runtime menganggap sebarang pengecualian yang tidak ditangkap sebagai fatal. Di sini, kegagalan tersebut menghalang pembantu e-mel berkuasa AI daripada berfungsi untuk mana-mana pengguna yang menaip baris subjek yang panjang—satu kesan langsung kepada pengalaman pengguna dan janji kebolehpercayaan platform tanpa pelayan (serverless).

Apa yang boleh dilakukan secara berbeza

Pembaikannya mudah, tetapi ia menyerlahkan langkah pengesahan yang terlepas. Sanitasi input yang menyemak panjang corak sebelum membina rentetan SQL akan dapat mengesan isu tersebut semasa pembangunan dan bukannya semasa pengeluaran.

Apa yang perlu diperhatikan seterusnya

Pembangun yang melancarkan SQLite pada runtime edge harus mengaudit semua pembinaan pertanyaan yang melibatkan pemadanan corak, terutamanya yang menambah simbol wildcard atau aksara melarikan (escape characters). Sentry menangkap baris tepat di mana SQLite gagal. Memandangkan pengkomputeran edge semakin mendapat tempat, had platform yang tersembunyi akan lebih kerap muncul, dan tabiat mengesahkan input terhadap kekangan yang didokumentasikan akan membuahkan hasil.

Rumusan: Siling 50-bait pada corak LIKE SQLite boleh menyebabkan Cloudflare Workers terhenti, tetapi pemotongan istilah carian kepada 48 aksara menghapuskan ralat tersebut tanpa sebarang beban tambahan—bukti bahawa langkah pengesahan yang kecil dapat mengekalkan kestabilan perkhidmatan edge.