Ранее в этом году SQLite выпустила версию 3.51.3, устранившую давнюю ошибку в подсистеме Write-Ahead Logging (WAL) — так называемый WAL-Reset bug. Баг существовал в коде с 2010 года, но команда SQLite узнала о нём только в этом году. В официальном сообщении об исправлении говорилось:
«Это состояние гонки данных с жёсткими временными ограничениями. Оно редко возникает при обычном использовании. Разработчикам никогда не удавалось воспроизвести баг органически, и им пришлось добавить в SQLite специальную тестовую логику, преднамеренно провоцирующую условия возникновения ошибки, чтобы подтвердить, что проблема действительно устранена».
Карл Сверре, старший инженер Antithesis, прочитал об этой истории во время автомобильной поездки с подругой — и, будучи давним поклонником баз данных, немедленно заинтересовался темой. Баги в SQLite традиционно считаются крайне редкими, а этот случай выглядел идеальным примером известной, сложной ошибки, которую можно было отследить с помощью Antithesis — подобные задачи в компании решали уже неоднократно в рамках пилотных проектов. К тому же незадолго до этого Сверре реализовал набор навыков (skills) для работы Claude с Antithesis.
Сидя на склоне холма на Sunshine Coast, он достал телефон и поручил Claude приступить к работе. Агент развернул в Antithesis версию SQLite 3.51.2 — ту, где баг ещё присутствовал, — и добавил в код набор ассертов Antithesis. Инструментированную версию можно посмотреть здесь.
Затем Claude написал простую нагрузку, которая одновременно запускала операции записи в WAL и чекпоинты. Важная деталь — нагрузка полностью универсальна: она просто выполняет параллельные записи и чекпоинты, что регулярно происходит в реальной эксплуатации. Ассерты также не были заточены специально под этот баг — это стандартные проверки, которые применимы к любой базе данных: «нет потерянных подтверждённых записей» и «база данных не повреждена» (в терминологии SQLite — integrity check).
В первом же прогоне Antithesis обнаружил баг за 15 минут. Полный отчёт доступен здесь. Ключевой фрагмент выглядит так:
После этого тест повторили на версии 3.51.3 с той же нагрузкой и той же инструментацией Antithesis. Прогон прошёл чисто.
Повод вернуться к этой истории появился, когда Tailscale опубликовала подробный разбор того, как компания устраняла проблемы с аптаймом, преследовавшие её в 2025 году. Именно эти проблемы в итоге привели команду SQLite к обнаружению WAL-Reset бага. Tailscale пережила шесть месяцев нестабильной работы, после чего вместе с разработчиками SQLite потратила недели на поиск причины, выпустила и откатила исправление, которое сломало другую функциональность, а затем ещё два месяца ждала, чтобы убедиться, что «настоящий» фикс (3.51.3) действительно работает.
Чтобы найти корневую причину, в Tailscale пришлось написать новый конвейер логирования транзакций, а также встроить в SQLite отдельный инструмент для отладки слоя виртуальной файловой системы. В Antithesis этот процесс не сводится буквально к одному клику, но один клик даёт причинно-следственный анализ, который локализует проблему с точностью до доли секунды, а также детерминированную отладку с перемещением во времени, позволяющую проигрывать сценарии «что если» и деструктивный анализ.
Команда Tailscale писала: «никто не хотел, чтобы мы шесть месяцев искали баги в SQLite. Это был крайне изматывающий опыт как для наших клиентов, так и для сотрудников».
Поиск багов уровня WAL-Reset — задача мучительно сложная, но настоящее испытание начинается позже, когда нужно ждать и проверять, действительно ли сработало исправление. Работа с множеством баз данных научила Сверре, что через это приходится проходить снова и снова.
Поэтому осознание того, насколько болезненным этот баг оказался в реальной эксплуатации, произвело двойственное впечатление — и отрезвляющее, и вдохновляющее одновременно. Дав агентам навыки работы с Antithesis, баг нашли и подтвердили исправление буквально за час, с телефона, сидя в тени елей под солнцем. Уверенность в том, что агентные навыки работают, была и раньше — но не в том, что они работают настолько хорошо.