Охота на баг в SQLite Подустали читать про ИИ, релиз очередной модели, результаты бенчмарков и новости про то, как хитрые агенты что-нибудь взломали? Если да, то почему бы не почитать лонгрид про то, как компания Tailscale искала в SQLite хитрый баг, который прятался в ней 16 лет?  🔜 Если кратко: Данные компания хранит в SQLite на отдельных серверах. Каждые несколько минут система делает «снимок» базы и отправляет файл SQLite в хранилище S3. Такой подход работал с 2023 года, но в августе 2025 начал сбоить — именно тогда Tailscale обнаружили, что один бекап поврежден. А потом этот случай повторился, а потом еще, и так 19 раз за 6 месяцев. В инцидентах не было никакой логики: они затрагивали разные сервера, данные разных клиентов, с разной частотой, независимо от нагрузки на сеть или времени суток. Пока компания искала баг, им надо было как-то поддерживать работоспособность продукта и постараться при этом не терять данные пользователей. Они стали вести отдельный лог всех изменений, которые после очередной поломки воспроизводили поверх последней исправной копии. Этот подход и подкинул в итоге важную подсказку: в двух случаях данные, которые одна транзакция успешно записала и сохранила, исчезли для всех последующих.  🔜 Потеря уже подтвержденных данных навела на мысль, что поломка происходит во время записи на диск. Тут надо вспомнить, как эта СУБД фиксирует новые данные: она сначала вносит их в WAL (Write-ahead-log), а затем уже переносит в базу — это называется checkpoint. Все это время Tailscale сотрудничали с разработчиками SQLite, которые создали инструмент, позволяющий детальнее посмотреть, что происходит в СУБД во время работы. Он и показал, что иногда во время чекпоинта SQLite ошибочно считала, что уже скопировала данные из WAL, хотя на самом деле еще не успела это сделать. Из-за этого часть записей терялась, но некоторые страницы в базе (например, индексы) продолжали на них ссылаться — в итоге весь файл повреждался. Баг сидел в коде 16 лет незамеченным, потому что воспроизвести его можно только в специфических условиях. Обычно чекпоинты проводятся автоматически и работают без ошибок, а Tailscale решили взять процесс под свой контроль и сделали это по их же словам, очень агрессивно. Именно это и приводило к сбоям, но больше так не будет: баг пофиксили в версии SQLite 3.52.0. 🔜 Вот такой хеппи энд. Хотя концовку вы уже знаете, почитать статью целиком все равно стоит. Во-первых, это хороший повод побольше узнать про то, что творится внутри одной из самых популярных СУБД, а во-вторых там есть сцена после титров.