Скрипт очищення, запущений на платформі публікації сайту, помилково ідентифікував фрагменти коду як некоректні змінні Liquid і видалив їх з усіх статей, де вони були присутні. Через цей збій десятки технічних публікацій залишилися без прикладів коду, на які покладаються читачі, що спричинило термінове відкочування змін та перегляд підходів до тестування міграції контенту.
Як цей баг просочився в систему
Платформа використовує Liquid — мову шаблонів, яка розмічає динамічний контент за допомогою таких тегів, як {{ … }}. Планова технічна робота мала на меті видалити зайві теги, що могли порушити рендеринг. Парсер скрипта шукав відкриваючі теги, для яких не було відповідного закриваючого тега, і, знайшовши такий, видаляв увесь блок, щоб «виправити» помилку.
На практиці парсер не зміг розпізнати теги {% raw %} та {% endraw %}, які оточують блоки коду. Ці теги вказують Liquid сприймати все всередині як звичайний текст, але помилковий скрипт сприйняв відкриваючий тег {% raw %} як незакриту змінну ({{% raw %}) і видалив код навколо нього. Зафіксоване повідомлення про помилку:
Liquid syntax error: Variable '{{% raw %}' was not properly terminated.
Оскільки скрипт працював безпосередньо з живим репозиторієм контенту, видалення відбулося масово, одним проходом стерши приклади коду з усіх уражених статей.
Що стоїть на кону
Технічні статті залежать від фрагментів коду для ілюстрації концепцій, відтворення результатів та покрокового керівництва читачів. Втрата цих блоків робить публікації майже марними, змушує авторів переписувати контент і підриває довіру до надійності платформи. Для сайту, чия репутація будується на якісній документації для розробників, цей інцидент загрожує як аудиторії, так і лояльності контриб'юторів.
Деталі, які більшість читачів пропускають
- Пакетна обробка без використання пісочниці — скрипт запускався безпосередньо на продуктивних даних, а не на staging-копії.
- Недостатня обробка тегів — було враховано лише частину тегів Liquid;
{% raw %}не було включено до білого списку. - Відсутність інкрементального тестування — завдання було розгорнуто на всьому наборі даних без попереднього пілотного запуску на невеликій вибірці.
Що могло б запобігти цьому
- Запускайте міграції на копії — спочатку застосовуйте будь-які масові трансформації до ізольованої версії бази даних (sandboxed version).
- Проводьте юніт-тестування парсерів на всіх варіантах тегів — включайте граничні випадки, такі як блоки
raw, теги коментарів та вкладені структури. - Поступове розгортання — обробляйте обмежену кількість статей, перевіряйте результати, а потім масштабуйте процес.
Контраргумент
Дехто стверджує, що тестування кожного скрипта на повному бекапі є непрактичним для сайтів, що швидко розвиваються, і що ризик втрати даних перекривається потребою у швидкому виправленні помилок. Хоча швидкість має значення, вартість скасування масового видалення — як у часі розробників, так і в репутаційних втратах — часто перевищує затримку, спричинену обережним розгортанням.
Що далі
Команда відновила відсутній код із резервних копій і зараз доопрацьовує інструмент очищення, щоб він розпізнавав усі конструкції Liquid. Вони планують опублікувати post-mortem з детальним описом оновленого робочого процесу тестування та оприлюднити виправлений скрипт, щоб інші видавці могли уникнути такої ж пастки. Цей інцидент слугує нагадуванням: навіть крихітна помилка парсингу може стерти тижні праці авторів, що робить ретельне тестування обов'язковою умовою.