SQLite LIKE 模式中一个隐藏的 50 字节限制，导致 Agentic Inbox 项目在尝试搜索长邮件主题时引发了 Cloudflare Workers 崩溃；将搜索字符串修剪至 48 个字符后，故障得以停止。

是什么破坏了边缘运行时

Agentic Inbox 在 Cloudflare Durable Object 内部运行每个邮箱，并使用嵌入式 SQLite 数据库进行存储。AI 驱动的代理会将搜索模式构建为 %search_term%。SQLite 对 LIKE 模式的总长度强制执行 50 字节的硬上限。当用户输入超过 48 个字符的主题时，周围的 % 符号会将模式长度推过该上限。SQLite 抛出了一个未处理的运行时错误，而受限的 Worker 环境将其视为致命错误。整个脚本终止，导致收件箱无法使用，AI 代理也随之失效。

故障是如何被发现的

Sentry 记录了来自 Workers 的未捕获异常。当崩溃发生时，Sentry 记录了 SQLite 抛出错误的准确行号。其 “Seer AI” 功能解析了堆栈跟踪，高亮显示了 LIKE 模式的构建过程，并指出模式长度是罪魁祸首。查阅 SQLite 的编译时文档后确认了这一 50 字节的限制，团队随后使用 Gemini 验证了该限制，并计算出了用户输入的安全最大长度。

精准修复

解决方案仅需在现有的搜索程序中进行三处微小的改动：

  • 对任何输入的搜索词实施 48 个字符的硬上限。
  • 在拼接 % 通配符之前，将输入字符串截断至该长度。
  • 保持查询的其他部分不变，在不引入新库的情况下保持搜索准确性。

由于调整发生在查询到达 SQLite 之前，最终的模式永远不会超过 50 字节的阈值，Worker 也不会再崩溃。没有添加额外的依赖，因此代码库保持了轻量化。

为什么这很重要

边缘托管数据库对于低延迟用例非常有吸引力，但它们继承了与本地版本相同的约束。当运行时将任何未捕获的异常视为致命错误时，一个模糊的编译时限制可能会变成阻碍生产环境运行的 Bug。在这里，这次崩溃导致任何输入长主题行的用户都无法使用 AI 驱动的邮件助手——这直接损害了用户体验，也违背了无服务器平台对可靠性的承诺。

有哪些可以改进的地方

虽然修复方法很简单，但它凸显了一个缺失的验证步骤。如果在构建 SQL 字符串之前进行检查模式长度的输入清理（Input sanitization），就能在开发阶段而非生产阶段发现这个问题。

后续注意事项

在边缘运行时部署 SQLite 的开发者应当审计所有涉及模式匹配的查询构建，特别是那些添加了通配符或转义字符的查询。Sentry 捕获了 SQLite 失败的准确行号。随着边缘计算的普及，隐藏的平台限制将会更频繁地出现，养成根据文档约束验证输入的习惯将会大有裨益。

核心结论： SQLite LIKE 模式的 50 字节上限可能会导致 Cloudflare Workers 崩溃，但将搜索词修剪至 48 个字符可以在不增加任何额外负担的情况下消除故障——这证明了一个微小的验证步骤就能保持边缘服务的稳定。