Một giới hạn 50-byte ẩn trong các mẫu LIKE của SQLite đã khiến Cloudflare Workers bị sập khi dự án Agentic Inbox cố gắng tìm kiếm các tiêu đề email dài, và việc cắt ngắn các chuỗi tìm kiếm xuống còn 48 ký tự đã ngăn chặn các lỗi này.

Điều gì đã làm hỏng edge runtime

Agentic Inbox chạy mỗi hộp thư bên trong một Cloudflare Durable Object, sử dụng cơ sở dữ liệu SQLite nhúng để lưu trữ. Agent điều khiển bằng AI xây dựng một mẫu tìm kiếm dưới dạng %search_term%. SQLite áp đặt một giới hạn cứng 50-byte cho tổng độ dài của một mẫu LIKE. Khi người dùng nhập một tiêu đề dài hơn 48 ký tự, các ký tự % bao quanh đã đẩy mẫu vượt quá giới hạn đó. SQLite đã ném ra một lỗi runtime không được xử lý, điều mà môi trường Worker bị hạn chế coi là lỗi nghiêm trọng (fatal). Toàn bộ script bị chấm dứt, khiến hộp thư không thể sử dụng và agent AI bị hỏng.

Cách phát hiện lỗi

Sentry đã ghi lại các ngoại lệ (exceptions) không được bắt từ các Workers. Khi sự cố sập xảy ra, Sentry đã ghi lại chính xác dòng mà SQLite báo lỗi. Tính năng “Seer AI” của nó đã phân tích stack trace, làm nổi bật phần xây dựng mẫu LIKE và gợi ý rằng độ dài của mẫu chính là nguyên nhân. Một cái nhìn nhanh vào tài liệu compile-time của SQLite đã xác nhận giới hạn 50-byte, và nhóm phát triển đã sử dụng Gemini để xác minh giới hạn này cũng như tính toán độ dài tối đa an toàn cho đầu vào của người dùng.

Cách khắc phục triệt để

Việc giải quyết yêu cầu ba thay đổi nhỏ, tất cả đều nằm trong quy trình tìm kiếm hiện có:

  • Áp đặt một giới hạn cứng 48 ký tự cho bất kỳ thuật ngữ tìm kiếm đầu vào nào.
  • Cắt chuỗi đầu vào theo độ dài đó trước khi nối các ký tự đại diện %.
  • Giữ nguyên phần còn lại của truy vấn, bảo toàn độ chính xác của tìm kiếm mà không cần thêm thư viện mới.

Vì việc điều chỉnh diễn ra trước khi truy vấn đến SQLite, mẫu cuối cùng không bao giờ vượt quá ngưỡng 50-byte, và Worker không còn bị sập nữa. Không có phụ thuộc (dependencies) bổ sung nào được thêm vào, vì vậy mã nguồn vẫn nhẹ nhàng.

Tại sao điều này lại quan trọng

Các cơ sở dữ liệu được lưu trữ tại edge rất hấp dẫn cho các trường hợp sử dụng có độ trễ thấp, nhưng chúng cũng thừa hưởng các ràng buộc tương tự như các phiên bản on-premises. Một giới hạn compile-time mơ hồ có thể trở thành một lỗi gây tắc nghẽn môi trường production khi runtime coi bất kỳ ngoại lệ không được bắt nào là lỗi nghiêm trọng. Ở đây, sự cố sập đã khiến một trợ lý email chạy bằng AI ngừng hoạt động đối với bất kỳ người dùng nào nhập tiêu đề dài—một tác động trực tiếp đến trải nghiệm người dùng và lời hứa về độ tin cậy của các nền tảng serverless.

Những gì có thể làm khác đi

Cách khắc phục rất đơn giản, nhưng nó làm nổi bật một bước xác thực đã bị bỏ lỡ. Việc làm sạch đầu vào (input sanitization) để kiểm tra độ dài mẫu trước khi xây dựng chuỗi SQL lẽ ra đã có thể phát hiện vấn đề trong quá trình phát triển thay vì ở môi trường production.

Những điều cần lưu ý tiếp theo

Các nhà phát triển triển khai SQLite trên các edge runtime nên kiểm tra lại tất cả các cấu trúc truy vấn có liên quan đến khớp mẫu (pattern matching), đặc biệt là những truy vấn có thêm các ký tự đại diện (wildcards) hoặc ký tự thoát (escape characters). Sentry đã ghi lại chính xác dòng mà SQLite gặp lỗi. Khi điện toán edge ngày càng phổ biến, các giới hạn nền tảng ẩn sẽ xuất hiện thường xuyên hơn, và thói quen xác thực đầu vào dựa trên các ràng buộc đã được tài liệu hóa sẽ mang lại hiệu quả.

Bài học rút ra: Giới hạn 50-byte đối với các mẫu LIKE của SQLite có thể làm sập Cloudflare Workers, nhưng việc cắt ngắn các thuật ngữ tìm kiếm xuống còn 48 ký tự sẽ loại bỏ lỗi mà không cần thêm bất kỳ gánh nặng nào—một minh chứng cho thấy một bước xác thực nhỏ có thể giữ cho các dịch vụ edge luôn ổn định.