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

Как пропустили этот баг

Платформа использует Liquid — язык шаблонов, который размечает динамический контент с помощью таких тегов, как {{ … }}. Плановая задача по обслуживанию должна была удалить лишние теги, которые могли нарушить рендеринг. Парсер скрипта искал открывающие теги, у которых отсутствовали соответствующие закрывающие, и при обнаружении такого тега удалял весь блок, чтобы «исправить» ошибку.

На практике парсер не смог распознать теги {% raw %} и {% endraw %}, которые оборачивают блоки кода. Эти теги указывают Liquid воспринимать всё содержимое как обычный текст, но ошибочный скрипт принял открывающий {% raw %} за незакрытую переменную ({{% raw %}) и удалил окружающий код. В логах была зафиксирована следующая ошибка:

Liquid syntax error: Variable '{{% raw %}' was not properly terminated.

Поскольку скрипт работал с основным репозиторием контента, удаление произошло массово: примеры кода были стерты из всех затронутых статей за один проход.

Что стоит на кону

Технические статьи опираются на фрагменты кода, чтобы иллюстрировать концепции, воспроизводить результаты и вести читателей через пошаговые процедуры. Потеря этих блоков делает посты практически бесполезными, заставляет авторов переписывать контент и подрывает доверие к надежности платформы. Для сайта, чья репутация строится на высококачественной документации для разработчиков, этот инцидент угрожает как читательской аудитории, так и лояльности контрибьюторов.

Детали, которые большинство читателей упускают из виду

  • Пакетная обработка без использования «песочницы» — скрипт запускался непосредственно на рабочих данных, а не на staging-копии.
  • Недостаточная обработка тегов — учитывалась лишь часть тегов Liquid; {% raw %} не был включен в белый список.
  • Отсутствие инкрементального тестирования — задача была развернута на всем наборе данных без предварительного запуска на небольшой выборке.

Что могло бы предотвратить это

  • Запускайте миграции на копии — сначала применяйте любые массовые преобразования к изолированной версии базы данных.
  • Проводите юнит-тестирование парсеров на всех вариациях тегов — включайте граничные случаи, такие как блоки raw, теги комментариев и вложенные структуры.
  • Постепенное развертывание — обработайте ограниченное количество статей, проверьте результаты, а затем масштабируйте процесс.

Контраргумент

Some argue that testing every script on a full backup is impractical for fast-moving sites, and that the risk of data loss is outweighed by the need for rapid fixes. While speed matters, the cost of undoing a mass deletion – both in developer time and reputational damage – often exceeds the delay introduced by a cautious rollout.

Что дальше

Команда восстановила недостающий код из резервных копий и пересматривает инструмент очистки, чтобы он распознавал все конструкции Liquid. Они планируют опубликовать post-mortem с подробным описанием обновленного процесса тестирования и публично поделиться исправленным скриптом, чтобы другие издатели могли избежать той же ошибки. Этот инцидент служит напоминанием: даже крошечная ошибка парсинга может стереть результаты недель работы авторов, что делает тщательное тестирование обязательным условием.