Ukryty limit 50 bajtów dla wzorców LIKE w SQLite spowodował awarie Cloudflare Workers podczas próby przeszukiwania długich tematów wiadomości e-mail w projekcie Agentic Inbox; skrócenie ciągów wyszukiwania do 48 znaków wyeliminowało błędy.

Co spowodowało awarię środowiska edge runtime

Agentic Inbox uruchamia każdą skrzynkę pocztową wewnątrz Cloudflare Durable Object, wykorzystując osadzoną bazę danych SQLite do przechowywania danych. Agent sterowany przez AI buduje wzorzec wyszukiwania jako %search_term%. SQLite narzuca sztywny limit 50 bajtów na całkowitą długość wzorca LIKE. Gdy użytkownik wpisał temat dłuższy niż 48 znaków, otaczające go znaki % sprawiły, że wzorzec przekroczył ten limit. SQLite wyrzuciło nieobsłużony błąd czasu wykonania (runtime error), który ograniczone środowisko Worker potraktowało jako krytyczny. Cały skrypt został przerwany, co uczyniło skrzynkę pocztową bezużyteczną, a agenta AI niesprawnym.

Jak odkryto błąd

Sentry logowało nieobsłużone wyjątki z Workerów. Gdy wystąpiła awaria, Sentry zarejestrowało dokładną linię, w której SQLite zgłosiło błąd. Funkcja „Seer AI” przeanalizowała ślad stosu (stack trace), wskazała na konstrukcję wzorca LIKE i zasugerowała, że przyczyną jest jego długość. Szybki przegląd dokumentacji SQLite dotyczącej czasu kompilacji potwierdził ograniczenie do 50 bajtów, a zespół wykorzystał Gemini, aby zweryfikować ten limit i obliczyć bezpieczną maksymalną długość danych wejściowych użytkownika.

Precyzyjna poprawka

Rozwiązanie wymagało trzech drobnych zmian, wprowadzonych w ramach istniejącej rutyny wyszukiwania:

  • Nałożenie sztywnego limitu 48 znaków na każdy przychodzący termin wyszukiwania.
  • Skrócenie ciągu wejściowego do tej długości przed dodaniem znaków wieloznacznych %.
  • Pozostawienie reszty zapytania bez zmian, co zachowuje dokładność wyszukiwania bez konieczności dodawania nowych bibliotek.

Ponieważ korekta następuje przed dotarciem zapytania do SQLite, końcowy wzorzec nigdy nie przekracza progu 50 bajtów, a Worker nie ulega już awarii. Nie dodano żadnych dodatkowych zależności, dzięki czemu baza kodu pozostaje lekka.

Dlaczego to ma znaczenie

Bazy danych hostowane na brzegu sieci (edge) są atrakcyjne w zastosowaniach wymagających niskich opóźnień, ale dziedziczą te same ograniczenia, co wersje on-premises. Nieoczywisty limit czasu kompilacji może stać się błędem blokującym produkcję, gdy środowisko uruchomieniowe traktuje każdy nieobsłużony wyjątek jako krytyczny. W tym przypadku awaria uniemożliwiła działanie asystenta e-mail opartego na AI każdemu użytkownikowi, który wpisał długi temat wiadomości – co bezpośrednio uderzyło w doświadczenie użytkownika i obietnicę niezawodności platform serverless.

Co można było zrobić inaczej

Poprawka jest prosta, ale uwypukla pominięty krok walidacji. Sanityzacja danych wejściowych, która sprawdza długość wzorca przed zbudowaniem ciągu SQL, pozwoliłaby wykryć problem na etapie rozwoju, a nie na produkcji.

Na co zwrócić uwagę w przyszłości

Deweloperzy wdrażający SQLite w środowiskach edge runtime powinni przeprowadzić audyt wszystkich konstrukcji zapytań zawierających dopasowywanie wzorców, zwłaszcza tych, które dodają znaki wieloznaczne lub znaki ucieczki. Sentry zarejestrowało dokładną linię, w której SQLite zawiodło. W miarę jak edge computing zyskuje na popularności, ukryte limity platform będą pojawiać się coraz częściej, a nawyk walidacji danych wejściowych względem udokumentowanych ograniczeń okaże się bardzo przydatny.

Wniosek: Limit 50 bajtów dla wzorców LIKE w SQLite może spowodować awarię Cloudflare Workers, ale skrócenie terminów wyszukiwania do 48 znaków eliminuje błąd bez zbędnego obciążenia – to dowód na to, że mały krok w walidacji może zapewnić stabilność usług edge.