Скрытое 50-байтовое ограничение на шаблоны LIKE в SQLite приводило к сбоям Cloudflare Workers, когда проект Agentic Inbox пытался выполнить поиск по длинным темам писем; ограничение поисковых строк 48 символами позволило устранить проблему.

Что нарушило работу edge runtime

Agentic Inbox запускает каждый почтовый ящик внутри Cloudflare Durable Object, используя встроенную базу данных SQLite для хранения. ИИ-агент формирует шаблон поиска в виде %search_term%. SQLite накладывает жесткое ограничение в 50 байт на общую длину шаблона LIKE. Когда пользователь вводил тему длиннее 48 символов, окружающие знаки % выводили длину шаблона за этот предел. SQLite выбрасывал необработанную ошибку выполнения (runtime error), которую ограниченная среда Worker воспринимала как фатальную. Весь скрипт завершался, из-за чего почтовый ящик становился недоступным, а ИИ-агент переставал работать.

Как был обнаружен баг

Sentry регистрировал необработанные исключения от Workers. Когда произошел сбой, Sentry зафиксировал точную строку, в которой SQLite выдал ошибку. Функция «Seer AI» проанализировала стек вызовов (stack trace), выделила конструкцию шаблона LIKE и предположила, что причиной является его длина. Быстрый просмотр документации SQLite на этапе компиляции подтвердил ограничение в 50 байт, а команда использовала Gemini, чтобы проверить этот лимит и рассчитать безопасную максимальную длину пользовательского ввода.

Точечное исправление

Решение потребовало трех крошечных изменений, внесенных непосредственно в существующую процедуру поиска:

  • Установить жесткий лимит в 48 символов для любого входящего поискового запроса.
  • Обрезать входную строку до этой длины перед добавлением подстановочных знаков %.
  • Оставить остальную часть запроса без изменений, сохраняя точность поиска и не добавляя новых библиотек.

Поскольку корректировка происходит до того, как запрос попадает в SQLite, итоговый шаблон никогда не превышает порог в 50 байт, и Worker больше не падает. Дополнительные зависимости не добавлялись, поэтому кодовая база остается легковесной.

Почему это важно

Базы данных, размещенные на edge-узлах, привлекательны для сценариев с низкой задержкой, но они наследуют те же ограничения, что и on-premises версии. Малоизвестное ограничение на этапе компиляции может стать критическим багом в продакшене, если среда выполнения воспринимает любое необработанное исключение как фатальное. В данном случае сбой привел к тому, что ИИ-помощник по электронной почте переставал работать для любого пользователя, вводившего длинную тему письма, — это прямой удар по пользовательскому опыту и обещанию надежности serverless-платформ.

Что можно было сделать иначе

Исправление простое, но оно указывает на пропущенный этап валидации. Санитизация входных данных, проверяющая длину шаблона перед формированием SQL-строки, позволила бы обнаружить проблему на этапе разработки, а не в продакшене.

На что обратить внимание в будущем

Разработчикам, развертывающим SQLite в edge-средах, следует провести аудит всех конструкций запросов, использующих сопоставление по шаблону, особенно тех, где добавляются подстановочные знаки или символы экранирования. Sentry зафиксировала именно ту строку, на которой SQLite выдал ошибку. По мере роста популярности edge-вычислений скрытые ограничения платформ будут проявляться чаще, поэтому привычка проверять входные данные на соответствие задокументированным ограничениям окупится.

Вывод: 50-байтовое ограничение на шаблоны LIKE в SQLite может привести к сбоям Cloudflare Workers, но ограничение поисковых запросов 48 символами устраняет проблему без лишнего усложнения кода — это доказательство того, что простой шаг валидации может обеспечить стабильность edge-сервисов.